Show HN: Appwrite – Open-Source and Self Hosted Firebase Alternative

by christyjacob4 • 4 years ago

326 118 4 years ago

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...

Magodo• 4 years ago

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

tr3ntg2• 4 years ago

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.

nicoburns2• 4 years ago

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.

vincentmarle3• 4 years ago

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.

eldad_fux17• 4 years ago

Yes, this is something we would consider in the long run. Functions are great, but not for every use case.

qbasic_forever• 4 years ago

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_fux17• 4 years ago

Thank you so much! We've been working very hard the last year, and looking back - yeh we did add a lot of stuff :)

vincentmarle3• 4 years ago

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?

eldad_fux17• 4 years ago

Not yet, but it's coming soon. Appwrite is not coupled to any database or other under the hood technology.

kiwicopple7• 4 years ago

I’m curious why Supabase didn’t suit your needs, especially since you’re looking for Postgres support?

(Disclosure: supabase ceo)

johnx123-up• 4 years ago

Just curious, did you try Hasura too?

lfkdev2• 4 years ago

Godot support would be awesome

eldad_fux17• 4 years ago

Something like this? https://github.com/GodotNuts/appwrite-sdk

cercatrova5• 4 years ago

Any comparison with Supabase, which is also a backend-as-a-service? [0]

[0] https://supabase.com/

stnguyen90• 4 years ago

Couple of points here: https://medium.com/geekculture/appwrite-frequently-asked-que...

eldad_fux17• 4 years ago

Both products are great, at Appwrite we created the majority of the product from scratch in aim to have tailored made dev-experience which was a big reason for starting the project from the first place.

spankalee2• 4 years ago

Supabase uses Postgres instead of a Firestore like database, so it's not really a clone of Firebase.

cercatrova5• 4 years ago

Postgres supports jsonb which I've used with Supabase to act as a Firebase analog. I just pushed all data into a JSON blob rather than setting up tables, it worked well, pretty much the same as how I used Firebase.

christyjacob412• 4 years ago

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...

kiru_io• 4 years ago

Seems pretty cool! One question, how do you finance the development?

eldad_fux17• 4 years ago

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.

tr3ntg2• 4 years ago

Congratulations. That's incredible news.

pan69• 4 years ago

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?

spankalee2• 4 years ago

This is the first "Firebase clone" I've seen that attempts to implement the Firestore database model. Neat!

eldad_fux17• 4 years ago

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.

yeldarb• 4 years ago

Is there a compatibility layer or migration guide for people looking to switch?

christyjacob412• 4 years ago

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.

peppertree2• 4 years ago

What's the pricing model for cloud.

brandonroberts• 4 years ago

We’ll share the pricing for Appwrite Cloud shortly, which will be transparent and simple. The open source version of Appwrite will be free, forever.

vinibrito• 4 years ago

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.

eldad_fux17• 4 years ago

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.

cercatrova5• 4 years ago

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.

fareesh• 4 years ago

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_fux17• 4 years ago

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.

bikamonki2• 4 years ago

Strictly speaking, if I spin up a droplet on DO and install Appwrite on it, it won't be a BAAS anymore, correct?

Sorry but "self-host your own BAAS" is an oxymoron.

IMO, developers who chose Firebase do not want to manage servers.

eldad_fux17• 4 years ago

100% right, we are working on a cloud edition that we hope to release soon. That said, their are a lot of use cases for self-hosting, and its also very cool to be able to deploy something as massive as this on your own localhost with a single command.

bikamonki2• 4 years ago

Awesome, I look forward to try your managed service.

js4ever• 4 years ago

You can launch a fully managed instance of Appwrite in 3 minutes on Elestio for $10/mo: https://elest.io/open-source/appwrite

We take care of deployment, security, backups, monitoring, alerts, OS and Software updates

We also give back part of the benefits to the open source project (we launched 2 weeks ago so we are still contacting all the projects owners currently ... Eldad you should get my email soon)

sergiomattei• 4 years ago

I see it as risk management: perhaps start out with the hosted option. If they pull a Parse (shut down development and company), you still have the option of moving it to self hosting.

aerovistae4• 4 years ago

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.

christyjacob412• 4 years ago

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!

aerovistae4• 4 years ago

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.

rectang2• 4 years ago

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.

vincentge6• 4 years ago

Firebase is great for Hackathons =D

wfme• 4 years ago

My experience is quite different to this. I’d be interested to know which features behaved differently to their documentation?

leros• 4 years ago

Do you have any plans to support relational database functionality like joins?

christyjacob412• 4 years ago

Yes we do plan to add support got joins, transactions, atomic operations and geo queries soon

u2077• 4 years ago

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?

turtlebacon• 4 years ago

Love seeing open source projects evolve like this. Great work guys!

eldad_fux17• 4 years ago

Thank you so much! The community support has been such a major part of our journey!

peppertree2• 4 years ago

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_fux17• 4 years ago

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• 4 years ago

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.

robertlagrant2• 4 years ago

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.

christyjacob412• 4 years ago

This is some really heart warming feedback! Thank you from the entire Appwrite team

robertlagrant2• 4 years ago

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_fux17• 4 years ago

Thank you

nhoughto• 4 years ago

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.

20220322-beans4• 4 years ago

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.

fiznool3• 4 years ago

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.

snapetom3• 4 years ago

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.

EgeAytin• 4 years ago

Great work, I just cant see authorization feature. How does Appwrite handles this key concept right now ?

christyjacob412• 4 years ago

API keys are used by Server SDKs ( or Admin SDKs in the Firebase world ) to authenticate and perform more crucial server side tasks using the API https://appwrite.io/docs/keys

fiznool3• 4 years ago

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?

[1] https://github.com/appwrite/sdk-generator

eldad_fux17• 4 years ago

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!

fiznool3• 4 years ago

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!

andreisbc• 4 years ago

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

wiradikusuma• 4 years ago

Do you guys have Firebase shim/adapter to easy transition?

Also, please take a look at CapRover, combining that with Appwrite might be a powerful combo (there's overlap).

dlohani• 4 years ago

Hey, we don't yet have a Firebase adapter, however it should be very easy to transfer using Firebase admin scripts (using firebase-tools) and Appwrite's Server Side SDK of your choice. If you need help you can always come to our discord https://appwrite.io/discord

Also, yes CapRover looks interesting, thank you for mentioning, we will look into how we can integrate/collaborate.

RileyJames• 4 years ago

I have a firebase project I need to move asap.

How quickly, realistically, could I move to your solution?

Do the API’s map directly? Sorta? Or is this inspired by? Is the migration a significant dev effort?

Ping me docs and I’d consider it immediately.

eldad_fux17• 4 years ago

Although we still haven't created a fully automated migration, this doesn't have to be a huge take, but it will be mainly be up to the way your app is integrated with Firebase and how coupled the two are.

For migrating you'll have to do two things, migrate your data and replace your Firebase API calls. Appwrite provides both REST and Realtime (WebSocket) APIs that should be replaced with any Firebase calls in your app. You can migrate your Firebase data to Appwrite by using the Appwrite Server SDK in one of your favorite languages (https://appwrite.io/docs/sdks).

bobbydreamer• 4 years ago

Why people want to move from firebase? Any reasons. It's a good db

mccorrinall2• 4 years ago

Google dependency. Like to self-host. Can scale cheaper(?).

rapnie• 4 years ago

Google dependency

Indeed. To me it seems crazy to use an advertisement agency to host so much of your app. And as a user from same perspective, if I find Firebase is used in your app, then it is an immediate no-go area. No matter how good it looks otherwise in terms of features and UX.

CamelRocketFish2• 4 years ago

Building on from firebase’ feature set, are there any plans to incorporate analytics/crashlytics?

christyjacob412• 4 years ago

Yes, definitely. But its something lower on the priority list ( from community feedback )

CamelRocketFish2• 4 years ago

Thanks for the reply :)

Show HN: Appwrite – Open-Source and Self Hosted Firebase Alternative

Related Stories