[HN Gopher] Show HN: Appwrite - Open-Source and Self Hosted Fire...
___________________________________________________________________
Show HN: Appwrite - Open-Source and Self Hosted Firebase
Alternative
Author : christyjacob4
Score : 168 points
Date : 2022-03-22 17:37 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| 20220322-beans wrote:
| 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 wrote:
| 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.
| u2077 wrote:
| 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?
| EgeAytin wrote:
| Great work, I just cant see authorization feature. How does
| Appwrite handles this key concept right now ?
| christyjacob4 wrote:
| 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
| cercatrova wrote:
| Any comparison with Supabase, which is also a backend-as-a-
| service? [0]
|
| [0] https://supabase.com/
| spankalee wrote:
| Supabase uses Postgres instead of a Firestore like database, so
| it's not really a clone of Firebase.
| cercatrova wrote:
| 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 wrote:
| 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...
| stnguyen90 wrote:
| Couple of points here: https://medium.com/geekculture/appwrite-
| frequently-asked-que...
| eldad_fux wrote:
| 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.
| kiru_io wrote:
| Seems pretty cool! One question, how do you finance the
| development?
| eldad_fux wrote:
| 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.
| tr3ntg wrote:
| Congratulations. That's incredible news.
| christyjacob4 wrote:
| Our amazing open source community keeps us going
| vincentge wrote:
| Thank you!
| pan69 wrote:
| 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 wrote:
| I'd assume the Redhat model, but who knows.
| eldad_fux wrote:
| 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 wrote:
| They have a cloud offering. Personally I'd rather pay for
| someone else to manage devops than myself.
| spankalee wrote:
| This is the first "Firebase clone" I've seen that attempts to
| implement the Firestore database model. Neat!
| eldad_fux wrote:
| 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 wrote:
| Is there a compatibility layer or migration guide for people
| looking to switch?
| christyjacob4 wrote:
| 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.
| robertlagrant wrote:
| 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.
| eldad_fux wrote:
| Thank you
| christyjacob4 wrote:
| This is some really heart warming feedback! Thank you from the
| entire Appwrite team
| christyjacob4 wrote:
| 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...
| qbasic_forever wrote:
| 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 wrote:
| Thank you so much! We've been working very hard the last
| year, and looking back - yeh we did add a lot of stuff :)
| lfkdev wrote:
| Godot support would be awesome
| eldad_fux wrote:
| Something like this? https://github.com/GodotNuts/appwrite-
| sdk
|
| :)
| vincentmarle wrote:
| 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_fux wrote:
| Not yet, but it's coming soon. Appwrite is not coupled to any
| database or other under the hood technology.
| kiwicopple wrote:
| I'm curious why Supabase didn't suit your needs, especially
| since you're looking for Postgres support?
|
| (Disclosure: supabase ceo)
| kpennell wrote:
| 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.
| kiwicopple wrote:
| Thanks for the feedback. We have these -
|
| Examples: https://supabase.com/docs/guides/examples
|
| React: https://supabase.com/docs/guides/with-react
|
| Is this the type of thing you're looking for? Perhaps
| they could be more prominent
| vincentmarle wrote:
| 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.
| ctxc wrote:
| 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.
| kiwicopple wrote:
| Thanks for the feedback. Extra snippets are a great idea,
| especially with Row Level Security which is a bit harder
| to google for.
|
| > when are Supabase Functions expected to be released?
|
| We're doing another Launch Week starting on Monday next
| week. You will enjoy Thursday's launch
| johnhenry wrote:
| Supabase Functions launching Thursday, March 31st, 2022!
| Magodo wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| What are the issues with self hosting Supabase?
| nicoburns wrote:
| 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 wrote:
| 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 wrote:
| 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.
| vincentge wrote:
| There's two ways to address this if you don't wanna
| maintain/host.
|
| There will be a hosted Appwrite Cloud option =>
| https://appwrite.io/cloud
|
| There is a way to do 1 click deployment on Digital Ocean
| Marketplace:
| https://marketplace.digitalocean.com/apps/appwrite
|
| With these options, you can put off the whole mess with
| devops, infra, and hosting to someone else :')
| eldad_fux wrote:
| Yes, this is something we would consider in the long run.
| Functions are great, but not for every use case.
| turtlebacon wrote:
| Love seeing open source projects evolve like this. Great work
| guys!
| eldad_fux wrote:
| Thank you so much! The community support has been such a major
| part of our journey!
| vinibrito wrote:
| 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 wrote:
| 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 wrote:
| What's the pricing model for cloud.
| brandonroberts wrote:
| 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.
| fareesh wrote:
| 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 wrote:
| 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.
| peppertree wrote:
| 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 wrote:
| 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.
| leros wrote:
| Do you have any plans to support relational database
| functionality like joins?
| christyjacob4 wrote:
| Yes we do plan to add support got joins, transactions, atomic
| operations and geo queries soon
| bikamonki wrote:
| 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 wrote:
| 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 wrote:
| Awesome, I look forward to try your managed service.
| aerovistae wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 ?
| aerovistae wrote:
| It was because I needed to run validation over the inputs
| sent to the server, and then update other data which the
| user themself did not have authorization to access.
| christyjacob4 wrote:
| Thanks a lot for clarifying . Makes sense :)
| combyn8tor wrote:
| You can validate the data with Firebase rules. The other
| data can be updated with Firebase functions. They listen
| for state changes on the relevant data and then update
| the data that the user does not have access to.
| aerovistae wrote:
| I'm sure it's technically possible, but things were
| starting to feel hackier and hackier and already the
| latency was a no-go, so the value proposition was
| becoming less convincing. I'm still using it for user
| auth though, that seems to work well so far.
| rectang wrote:
| 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 wrote:
| My experience is quite different to this. I'd be interested
| to know which features behaved differently to their
| documentation?
| rectang wrote:
| 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 wrote:
| Firebase is great for Hackathons =D
| fiznool wrote:
| 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_fux wrote:
| 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!
___________________________________________________________________
(page generated 2022-03-22 23:00 UTC)