Get the top HN stories in your inbox every day.
christyjacob4
vincentmarle
I was about to throw in the towel after evaluating Firebase / Supabase last week for a new project I'm working on and revert back to good o'l Laravel, but Appwrite looks very interesting and could potentially solve my problem so I'll definitely check it out!
Just one question: is there also Postgres support?
kiwicopple
I’m curious why Supabase didn’t suit your needs, especially since you’re looking for Postgres support?
(Disclosure: supabase ceo)
ctxc
Hi, when are Supabase Functions expected to be released?
I'm quickly reaching a point in my project where direct DB calls don't cut it and I don't want to muck about with PG functions especially since I'm familiar with other programming languages. :(
Some suggestions: Using Supabase took me 5x the amount of time it should have taken me, honestly. 1. There needs to be more official snippets, PG especially. Create view, modify table, change constraints, and so on. If I'm your target demographic, it pays to watch issues raised/FAQs and integrate it in the UI. For example, I'm not very familiar with SQL and PG features. I had to learn the hard way that RLS does not apply to views. Basic for someone who knows DBs? Maybe. But I'm someone who wants to ship my product and my expertise is elsewhere. Would have loved to see this info in the UI.
2. Some things are just so hard to find! I spent a lot of time looking for something so simple. I think it was views? And also something under user authentication, I don't remember. Maybe you would benefit from user research - get a dev who hasn't used Supabase before, watch them build something with this and then address pain points.
kpennell
For me, if I want to move quickly, there's just so many great example React + Firebase projects out there. It's so easy to get started, even if I would prefer to work with postgres over nosql. I could have just missed it in the docs or elsewhere, but I couldn't seem to find a really easy to follow todo or chat app or something like that. I created a database I think and then just had little idea how I'd tie it all together with my front-end. So I went back to firebase for an MVP.
mccorrinall
https://appwrite.io/docs/installation
https://appwrite.io/docs/production
I would really love to see something like this in the supabase docs. They are currently lacking a little bit for running a self hosted supabase instance for production.
vincentmarle
Basically the lack of cloud functions (need a place somewhere to run my backend code ) and the Hook Events being in alpha. I know you're working on it but for my project these features are critical.
When Supabase Functions are live and Hooks are stable then it will definitely work for the app I'm working on.
girishso
I was trying Supabase on a toy project in Elm, ran into a weird CORS error. Even in React when using supabase-js the api call works, but using `fetch` (copied from chrome dev console) in dev console fails with CORS error. Supabase-js does something, which is not visible in the dev console.
Asked on Discord on two different channels after googling it for a while, no response whatsoever.
Supabase seems like a fine project, but without someone answering these kind of queries it's impossible to use.
eldad_fux
Not yet, but it's coming soon. Appwrite is not coupled to any database or other under the hood technology.
johnx123-up
Just curious, did you try Hasura too?
qbasic_forever
Wow, that's an impressive set of features! I remember kicking the tires on the service a year ago and liked it but didn't have a big need for it. It looks like a lot of great stuff has been added in the time since then.
eldad_fux
Thank you so much! We've been working very hard the last year, and looking back - yeh we did add a lot of stuff :)
nicoburns
I put this on Supabase's launch post too, but would you consider supporting a more traditional compute model? i.e. the ability to run an always-on docker container that runs a web server or similar (similar to dokku or heroku). I realise functions are the new hotness, but as far as I can see for non hobby projects they mainly have downsides any very little upside.
vincentmarle
From their readme it looks like you can host it however you want:
> Appwrite backend server is designed to run in a container environment. Running your server is as easy as running one command from your terminal. You can either run Appwrite on your localhost using docker-compose or on any other container orchestration tool like Kubernetes, Docker Swarm, or Rancher.
nicoburns
Hmm... I think I'm not quite the target market. For me the whole point of a tool like this is that I don't need to worry about maintaining this kind of thing. All the guff around auth and functions is just stuff I have to put up with to get that hosted niceness.
eldad_fux
Yes, this is something we would consider in the long run. Functions are great, but not for every use case.
Magodo
Thank you so much for Appwrite! The community on Discord is very helpful and the self hosting guide is great. Very unlike my terrible experience with Supabase who seem to do their best to cripple the self hosted option
tr3ntg
I was hoping someone here would compare the two. I might have to give Appwrite a try after all. Supabase's self-hosted option was wack when I tried it a few months ago.
vincentge
My honest two cents, which is biased, so take liberal amounts of salt.
I think Supabase is verbose. You get to dig around the PostgreSQL instance, write SQL, etc. I know people that live and die by SQL, so if that sounds like you, Supabase is great.
Appwrite is more about simplicity. Our SDKs are simple, our UI is simple, our Documentation is simple, heck we even have a 1 line deploy: docker run -it --rm \ --volume /var/run/docker.sock:/var/run/docker.sock \ --volume "$(pwd)"/appwrite:/usr/src/code/appwrite:rw \ --entrypoint="install" \ appwrite/appwrite:latest
Use a part of Appwrite, or all of it. Heck, go dig in our code or checkout our open sourced Functions runtime. We don't care, we just want you to do more while writing less code.
Both have their audience, both are great, see which one suits your needs better :)
eldad_fux
Our self-hosted solution was designed to be easy to setup in both development and production. I hope you'll enjoy our single command installation.
Also, self-hosting is at the core of what we do and once our cloud solution is out, we don't plan to add weird disabilities to it.
20220322-beans
What are the issues with self hosting Supabase?
lfkdev
Godot support would be awesome
20220322-beans
From my quick research when I was selecting the next backend I was going to use for a project in the past, and today reading some responses on this page:
- Appwrite is written in PHP. Just because something is open source, doesn't mean it is extensible, scalable or otherwise written well. I haven't seen many popular projects written in PHP recently. The only time I used PHP was in university, where the PHP application was the target machine in a CTF.
- AppWrite doesn't yet have their Cloud version, so they aren't ready to be a "backend as a service" - it's a product that isn't ready "as a service". That's why I didn't use it, and I can see similar sentiment here on HN. I'd be willing to try it out when it's ready.
- It's not built on Postgres. Their comment about Supabase using postgres did not include any real substance: "I'm trying to be as objective as I can, but building the entire ecosystem around a single product like Postgres ( even though tried and tested ) comes with its own downsides...". The downsides of what AppWrite might be that they're rolling their own database... in PHP? They may not be database experts, and there's lots to think about and fix when building a database, and Postgres has been tested for a long time.
- Not much progress is happening on the GraphQL side: https://github.com/appwrite/appwrite/pull/974/files, whereas Supabase has it: https://supabase.com/blog/2021/12/03/pg-graphql.
Overall, it seems like the project doesn't move as fast as its competitor (primarily Supabase) for features I care about, and perhaps this is caused by PHP?
Anyway, I'd love to hear your thoughts about my comments, Eldad and team.
fiznool
Not the OP but just wanted to weigh in on the PHP point. Just because it isn’t the coolest/hottest language around, doesn’t make PHP any less suitable for a project like this. Laravel in particular has been a game changer for modern PHP-based backends and sites, and the language itself has been steadily evolving and improving. It may not get the column inches of the likes of Phoenix or Remix, but it is stable, battle hardened and fully suitable for the majority of use cases in 2022.
snapetom
Plus the comment about it being not built on Postgres is absurd.
Postgres is great, but if something is not built on Postgres, it's bad? Use the right tool for the job. This looks like a combination of Redis and Maria, two great products with two different use cases which tells me the developers did think carefully about their architecture.
20220322-beans
Can you elaborate what you mean by "comment about not built on Postgres is absurd? I said "It's not built on Postgres.", but I didn't say that was necessarily bad - though it is likely depending on the circumstances. Again, same for PHP, likely bad, but you'd need to know the circumstances, which is why I made the post.
My statement was a response to their employee's comment about the downsides of Postgres, which I quoted. I didn't say what avoiding Postgres is bad, 1. I quoted their unbacked comment, and then 2. I explained it is not bad to use Postgres and actually it's worse to roll your own database. Not sure where you got the fact they use Redis and Maria, that is not very clear on their website, but I found an article on Github: https://github.com/appwrite/appwrite/blob/master/CONTRIBUTIN...
It's much easier to understand Supabase (they use Postgres) vs. AppWrite (I could not find out what they use). They did mention their "new database: completely rewrote the Appwrite data management layer". https://medium.com/appwrite-io/everything-you-need-to-know-a...
aerovistae
Before I even look into it, I'll tell you this: the headline was enough to grab my attention on its own. I strongly feel this is a badly underserved niche and I've had major issues with Firebase's limitations. You definitely have a winning idea here in this user's opinion.
rectang
I'd consider myself fortunate if I never have to deal with Firebase again.
Firebase simply did not behave as documented. Whole features shipped that were just wishful thinking.
It reeked of high-level management applying pressure to ship-now-no-matter-how-broken.
wfme
My experience is quite different to this. I’d be interested to know which features behaved differently to their documentation?
rectang
I most vividly recall unit testing, storage emulator, auth. For example:
https://github.com/firebase/firebase-js-sdk/issues/5086
> Steps to reproduce:
> Step 1: Read the documentation for setting up cloud storage unit tests at: https://firebase.google.com/docs/rules/unit-tests#storage
> Step 2: Attempt to write unit tests following the examples in the documentation
The reporter describes five problems which will thwart you when you try to write code according to the official documentation.
How did these docs ship? Did nobody ever try the sample code and verify that the features worked as advertised? Did nobody write any tests to validate that the features actually worked? Are there no policies in place (e.g. "new features require tests" or perhaps code review) to prevent such mishaps?
vincentge
Firebase is great for Hackathons =D
christyjacob4
That's great feedback and more validation to the problem we're solving. Glad to hear that. Would love to hear if there are any specific pain points with Firebase that you'd like to be addressed. Being an open source project thats the biggest advantage we have over Firebase. The community!
aerovistae
For me the most painful part was latency, and especially cloud function latency. I wanted to create an entire API through cloud functions and rapidly discovered that they have major issues with "cold startup". A lot of people have had this issue~ https://stackoverflow.com/questions/42726870/firebase-cloud-...
I found a lame workaround by setting up a cronjob to ping the API regularly, but there was still bad latency for cloud functions that were interacting with the database. It was 1-2s of latency, which was a total nonstarter for my realtime collaboration code. I had to go write a socket.io server by hand instead.
Also, there are extremely limited tools for observability/monitoring/logging of cloud functions, as well as for plain API interactions with firestore. I could see that trying to track down issues through that toolset was going to be nightmarish. In my opinion, for any app that scales beyond a small personal project, it is an absolute must to have good tools for inspecting logs with error rate graphs and stacktraces and so on.
christyjacob4
Thanks a lot for taking the time to type this. Really appreciate this.
If I understood everything correctly, may I ask why you were using a cloud function to build the a realtime application rather than relying on their realtime database directly ?
undefined
fiznool
I was about to ask how you manage to support so many different language bindings, then I noticed that you’ve built an ‘SDK generator’ [1]. Very cool! I’ve not come across this concept before - how does it work?
eldad_fux
We use twig templating syntax as an agnostic language that allow contributors from different coding backgrounds to help us build the SDK templates. Then we use our API spec file to auto-generate the source code and push the relevant code to the SDK repos and package manager, it works really well and help us maintain a big amount of SDKs with little overhead after the core templates are done. We actually plan to have a talk about, it's really cool!
fiznool
Awesome job. I guess the API spec file is key to this! I see from the repo that you use swagger.
Best of luck with the project - as others have noted, this is a space ripe for improvement given the success of the closed source incumbent that is Firebase. I still mourn the loss of Parse!
robertlagrant
I'm pretty wary of this sort of thing, but I've got to say, what you've produced looks awesome, and I will be thinking of a product to try it on!
I know it sounds silly to say this, but the polish and content of your website really helps. Very, very impressed.
nhoughto
I had the same sentiment, I was thinking is this the localstack of the Firebase world? have you doomed yourself to replicate their problems? but no its a firebase _alternative_ not a replacement, well played. Lots of good explainer content too.
christyjacob4
This is some really heart warming feedback! Thank you from the entire Appwrite team
robertlagrant
It's a pleasure! Let me reward you with another feature suggestion :)
In my world, one thing that's always a little troubling is a document DB, particularly around doing analytics. Having an accompanying way to do that would be extremely handy. E.g. eventually consistent streaming of documents to postgres, which I could then use to drive some screens.
eldad_fux
Thank you
andreisbc
I've been looking into supabase for a long time, trying to decide if i want to adopt it, but after many months of keeping an eye on them, appwrite comes along and i'm instantly sold. For me it means two things: supabase never really convinced me, and second, i was waiting for someone else to take the lead. Supabase is just fancy ui and marketing, while these guys seem the real deal. For home projects i'll just easily install appwrite(while i cannot do that with supabase after all these months of waiting), and for commercial apps i'm willing to pay appwrite to take care of infra and everything. Way to go guys, hats down and respects
u2077
I actually bookmarked the repo a few months ago but never got around to using it. Seems like a great product.
As someone who is building a small project for personal use (and has been frustrated with Firebase in the past) how does this compare? Will it be easy to switch an existing project over? Also, what is the plan for pricing on the hosted option?
kiru_io
Seems pretty cool! One question, how do you finance the development?
eldad_fux
Appwrite started as an open-source project 2 years ago. Last year we started a company and got a $10m seed from top VCs like Bessemer and Flybridge (ex-Firebase investors) to help us grow the community and speed product development.
pan69
Just out of curiosity. Why would a VC invest $10m in an Open Source project? I'd like to understand more about this model. You must have some path to a commercial offering I assume?
cercatrova
They have a cloud offering. Personally I'd rather pay for someone else to manage devops than myself.
sauwan
I'd assume the Redhat model, but who knows.
tr3ntg
Congratulations. That's incredible news.
christyjacob4
Our amazing open source community keeps us going
vincentge
Thank you!
fareesh
What would be great is an agnostic layer that's just the real-time sync that you can plug your existing stack into. Sending json up and down your websockets to sync things and handling offline etc is tedious and slow.
eldad_fux
That is exactly our plan! We like to decouple the different Appwrite components. This allows us to offer max flexibility for developers and let everyone use the server the way they like to. Using the REST API, Realtime or GraphQL with or without offline support - your call.
vinibrito
Sounds too good to be true. Are you saying that I, as a web developer, will be able to not touch devops stuff?
Does it work out of the box with everything included?
Because I really like only writing business logic.
cercatrova
You should look into backend-as-a-service products because this is exactly what they do. Firebase is the classic but proprietary example with Appwrite and Supabase are up and coming open source examples.
eldad_fux
Our aim is to try and reduce the friction during development as much as possible, but still leave developers max flexibility to build any products they like without limiting their creativity.
peppertree
Maybe I'm looking in the right place but I couldn't find docs on scaling. How does Appwrite scale up WS connection pool, workers, cloud functions.
eldad_fux
All of the Appwrite containers were designed to be stateless and easy to scale with replication, scaling the under the hood database is as easy as connecting it to a managed cloud solution.
zyang
I was wondering about the same thing. Is there instructions on how to scale the containers. Is it just matter of updating docker compose file or are there other configuration files I need to touch.
vincentge
We don't have instructors for this, per-se. There is an older article about using docker swarm -> https://dev.to/appwrite/30daysofappwrite-docker-swarm-integr...
We're trying to update these old posts as we speak... hopefully we'll get to this soon :') Keep an eye out!
spankalee
This is the first "Firebase clone" I've seen that attempts to implement the Firestore database model. Neat!
yeldarb
Is there a compatibility layer or migration guide for people looking to switch?
christyjacob4
Hi, at this point the process is not so straight forward and you'll need to use the Admin SDK from Firebase and the Server SDK from Appwrite to manually copy your data over. We do plan on making this easier in the future.
eldad_fux
Thank you! Actually the Firebase has done an amazing job on making the DB scalable, and we got to appreciate their work even more when working on our implementation.
Get the top HN stories in your inbox every day.
Over the past few months we’ve been trying hard to make Appwrite as simple to setup and use as possible. Your candid feedback has been crucial in shaping the project and it would be great if you can share some features you’d like to see in the project going forward.
What is Appwrite ? In simplest terms, Appwrite is an open source Backend As A Service (aka BaaS). Appwrite is an all in one solution with all the essentials you need like Authentication, User Management, Realtime Databases, Webhooks, Storage, Cloud Functions, SDKs for your favourite language and it’s light weight. Appwrite even runs on a Raspberry Pi. Most importantly, Appwrite is self-hosted which means you own your data and prevent any vendor lock-ins.
Talking about Appwrite’s features - Realtime Databases and events ( Recent benchmarks have showed a single server handling 1M+ concurrent connections )
- SDKs for iOS, Android, Flutter, Web ( React, Angular, Vue, Svelte etc.) Python, PHP, Node, Deno, Kotlin and more
- Bring your own Database - Use your choice of SQL or MySQL databases ( MariaDB, MySQL, MongoDB and more )
- Database permissions for finer tuned access control
- Storage API with built in encryption, compression and antivirus
- Bring your own Storage - Use your choice of the local filesystem, DigitalOcean Spaces, S3 or an any other storage provider of your choice
- Cloud functions with support for over 20 runtimes
- Webhooks to connect with 3rd party APIs and services
- User Management and Authentication
- Multiple authentication methods - email, 25+ OAuth providers, JWT, API Keys
- Completely stateless and extensible architecture allowing easy integration with your existing backend
- A Dashboard, CLI and VSCode extensions to manage your server and many more...