12 ms·

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

326 points by christyjacob4 5y ago

peppertree 5y ago
What's the pricing model for cloud.
- brandonroberts 5y 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.
bikamonki 5y 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_fux 5y 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.
  - bikamonki 5y ago
    Awesome, I look forward to try your managed service.
- js4ever 5y ago
  You can launch a fully managed instance of Appwrite in 3 minutes on Elestio for $10/mo: https://elest.io/open-source/appwrite 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 5y 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.
leros 5y ago
Do you have any plans to support relational database functionality like joins?
- christyjacob4 5y ago
  Yes we do plan to add support got joins, transactions, atomic operations and geo queries soon
christyjacob4 5y 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 5y 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
  - tr3ntg 5y 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.
cercatrova 5y ago
Any comparison with Supabase, which is also a backend-as-a-service? [0] [0] https://supabase.com/ https://supabase.com/
- stnguyen90 5y ago
  Couple of points here: https://medium.com/geekculture/appwrite-frequently-asked-questions-374ce81513fe#461c https://medium.com/geekculture/appwrite-frequently-asked-que...
- eldad_fux 5y 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.
- spankalee 5y ago
  Supabase uses Postgres instead of a Firestore like database, so it's not really a clone of Firebase.
  - cercatrova 5y 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.
  - christyjacob4 5y 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 5y ago
Seems pretty cool! One question, how do you finance the development?
- eldad_fux 5y 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.
  - pan69 5y 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?
    - sauwan 5y ago
      I'd assume the Redhat model, but who knows.
      - eldad_fux 5y ago
        Yes. Luckily a lot of amazing open-source companies like RedHat, Gitlab, Sentry, MongoDB and Elastic have already demonstrated multiple ways to build successful open-source business models, this is one area we don't need to reinvent the wheel at.
        cercatrova 5y ago
        I can't tell if this is sarcastic or not since many of those companies are either open core, or they moved from open source licenses to proprietary source-available licenses.
    - cercatrova 5y ago
      They have a cloud offering. Personally I'd rather pay for someone else to manage devops than myself.
spankalee 5y ago
This is the first "Firebase clone" I've seen that attempts to implement the Firestore database model. Neat!
- eldad_fux 5y 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 5y ago
  Is there a compatibility layer or migration guide for people looking to switch?
  - christyjacob4 5y 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.
vinibrito 5y 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_fux 5y 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.
- cercatrova 5y 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 5y 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_fux 5y 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.
aerovistae 5y 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.
- christyjacob4 5y 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!
  - aerovistae 5y 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-functions-is-very-slow?rq=1 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 5y ago
      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 ?
u2077 5y 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 5y ago
Love seeing open source projects evolve like this. Great work guys!
- eldad_fux 5y ago
  Thank you so much! The community support has been such a major part of our journey!
peppertree 5y 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_fux 5y 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 5y 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.
    - vincentge 5y ago
      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-integration-2io9 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!
robertlagrant 5y 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.
- christyjacob4 5y ago
  This is some really heart warming feedback! Thank you from the entire Appwrite team
  - robertlagrant 5y 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_fux 5y ago
  Thank you
- nhoughto 5y 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-beans 5y 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 https://github.com/appwrite/appwrite/pull/974/files, whereas Supabase has it: https://supabase.com/blog/2021/12/03/pg-graphql 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 5y 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.
  - snapetom 5y 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 5y ago
Great work, I just cant see authorization feature. How does Appwrite handles this key concept right now ?
- christyjacob4 5y 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 https://appwrite.io/docs/keys
fiznool 5y 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 https://github.com/appwrite/sdk-generator
- eldad_fux 5y 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!
  - fiznool 5y 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 5y 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
goldforever 5y ago
wiradikusuma 5y 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 5y 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 https://appwrite.io/discord Also, yes CapRover looks interesting, thank you for mentioning, we will look into how we can integrate/collaborate.
RileyJames 5y 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_fux 5y 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 https://appwrite.io/docs/sdks).
bobbydreamer 5y ago
Why people want to move from firebase? Any reasons. It's a good db
- mccorrinall 5y ago
  Google dependency. Like to self-host. Can scale cheaper(?).
  - rapnie 5y 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.
CamelRocketFish 5y ago
Building on from firebase’ feature set, are there any plans to incorporate analytics/crashlytics?
- christyjacob4 5y ago
  Yes, definitely. But its something lower on the priority list ( from community feedback )
  - CamelRocketFish 5y ago
    Thanks for the reply :)
    - christyjacob4 5y ago
      Anytime :)

326 points by christyjacob4 5y ago

peppertree 5y ago

What's the pricing model for cloud.

brandonroberts 5y 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.

bikamonki 5y 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_fux 5y 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.
- bikamonki 5y ago
  Awesome, I look forward to try your managed service.
js4ever 5y ago
You can launch a fully managed instance of Appwrite in 3 minutes on Elestio for $10/mo: https://elest.io/open-source/appwrite 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 5y 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.

leros 5y ago

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

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

christyjacob4 5y 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 5y 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
- tr3ntg 5y 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.

cercatrova 5y ago

Any comparison with Supabase, which is also a backend-as-a-service? [0] [0] https://supabase.com/ https://supabase.com/

stnguyen90 5y ago
Couple of points here: https://medium.com/geekculture/appwrite-frequently-asked-questions-374ce81513fe#461c https://medium.com/geekculture/appwrite-frequently-asked-que...
eldad_fux 5y 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.
spankalee 5y ago
Supabase uses Postgres instead of a Firestore like database, so it's not really a clone of Firebase.
- cercatrova 5y 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.
- christyjacob4 5y 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 5y ago

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

eldad_fux 5y 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.
- pan69 5y 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?
  - sauwan 5y ago
    I'd assume the Redhat model, but who knows.
    - eldad_fux 5y ago
      Yes. Luckily a lot of amazing open-source companies like RedHat, Gitlab, Sentry, MongoDB and Elastic have already demonstrated multiple ways to build successful open-source business models, this is one area we don't need to reinvent the wheel at.
      - cercatrova 5y ago
        I can't tell if this is sarcastic or not since many of those companies are either open core, or they moved from open source licenses to proprietary source-available licenses.
  - cercatrova 5y ago
    They have a cloud offering. Personally I'd rather pay for someone else to manage devops than myself.

spankalee 5y ago

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

eldad_fux 5y 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 5y ago
Is there a compatibility layer or migration guide for people looking to switch?
- christyjacob4 5y 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.

vinibrito 5y 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_fux 5y 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.
cercatrova 5y 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 5y 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_fux 5y 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.

aerovistae 5y 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.

christyjacob4 5y 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!
- aerovistae 5y 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-functions-is-very-slow?rq=1 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 5y ago
    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 ?

u2077 5y 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 5y ago

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

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

peppertree 5y 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_fux 5y 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 5y 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.
  - vincentge 5y ago
    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-integration-2io9 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!

robertlagrant 5y 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.

christyjacob4 5y ago
This is some really heart warming feedback! Thank you from the entire Appwrite team
- robertlagrant 5y 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_fux 5y ago
Thank you
nhoughto 5y 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-beans 5y 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 https://github.com/appwrite/appwrite/pull/974/files, whereas Supabase has it: https://supabase.com/blog/2021/12/03/pg-graphql 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 5y 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.
- snapetom 5y 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 5y ago

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

christyjacob4 5y 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 https://appwrite.io/docs/keys

fiznool 5y 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 https://github.com/appwrite/sdk-generator

eldad_fux 5y 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!
- fiznool 5y 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 5y 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

goldforever 5y ago

wiradikusuma 5y 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 5y 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 https://appwrite.io/discord Also, yes CapRover looks interesting, thank you for mentioning, we will look into how we can integrate/collaborate.

RileyJames 5y 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_fux 5y 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 https://appwrite.io/docs/sdks).

bobbydreamer 5y ago

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

mccorrinall 5y ago
Google dependency. Like to self-host. Can scale cheaper(?).
- rapnie 5y 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.

CamelRocketFish 5y ago

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

christyjacob4 5y ago
Yes, definitely. But its something lower on the priority list ( from community feedback )
- CamelRocketFish 5y ago
  Thanks for the reply :)
  - christyjacob4 5y ago
    Anytime :)