This way you can plug and play any of your existing infrastructure and services and turn them into your own private Firebase.
Finally, because we "introspect" all your data sources, we get end-to-end type safety. We don't just generate an API for you but also a truly type safe client.
Controlling everything from backend to API client allows for a lot of optimizations, e.g. the generated client knows if authentication is required to fire off a Query and therefore waits until the user is authenticated.
If you have any questions or feedback, feel free to join our discord: https://wundergraph.com/discord
We're going OSS 100% soon, exciting times ahead..
I'm sure a lot of devs mostly get started by reading docs, but I personally love videos which show me what's possible and I follow along.
- Postgres DB (+ admin panel + realtime sync + search + workflows)
- Auth
- Storage
- Functions (beta)
(disclosure: am small angel investor)
its interesting that you consider workflows a "standard cloud primitive". what do you currently use? (i work on a workflow engine myself)
Perhaps the dust on best practices / tech for workflows or sagas just hasn't settled yet to include in a framework like the one I am envisioning.
In general I think Supabase is fantastic in terms of the interoperability of all of the features they introduce. Just waiting on functions (and perhaps events / queues for async communication).
meanwhile if you like workflows as code and want to stay in the AWS world what about AWS SWF? our CEO used to be tech lead of that and it shares similar ideas.
yeah we are hoping to establish what best practice/architecture for workflows looks like. Feedback/questions welcome: https://docs.temporal.io/blog/workflow-engine-principles
It allows you to define task queues or scheduled jobs, and if you're already running Postgres you don't have to host any other infrastructure!
I’d pay more to get eur datacenter, but not that much when I can host it myself for $5 on DO with the same performance (for my usage)
Would gladly pay to support them, so I have given them feedback on my pereicament
> "I can host it myself for $5 on DO with the same performance (for my usage)"
If you check here:
https://hasura.io/docs/latest/graphql/cloud/index.html#hasur...
And look under "Features" and "Security" you can get a decent idea of what the differences are between OSS and the Cloud product.
There's 2 demographics I think Cloud stands out to -- those who want convenience ("I don't want to think about/manage my own instance"), and those who want an integrated APM tool or more security & access-control features, or are working on teams/orgs.
> Would gladly pay to support them, so I have given them feedback
I don't know enough (or really anything) about the business side though. It could be that $99 might be the only number where it starts to make sense to offer this sort of thing, based on infra costs/complexity. Or this could be the stupid thing I've ever said. I'm not a Cloud-Scientist ;^)
.. oh, and keep up the good work. I really do love the product!
And Vercel itself allows you to install backend services such as Redis caching, databases, or queues that you can pull in from those functions.
/snark
I'd think of a Next-driven BE as a BE for FE. And since it's co-located, You can share types, validators, utilities, (mental) models, etc. across the same codebase.
A technique that does have its place. Not always. Maybe not even half the time. But cleverer people than me use it to some effect.
Vercel itself I believe runs on a combination of Google Cloud and AWS.
Ideally I just get an endpoint from my backend-as-a-service (Supabase style) I can pop into Vercel as an environment variable, and use it as well in my moblile apps, public api, etc.
I had used both proprietary & open-source Parse until 4 years back for several production applications but has since gone back to relational DB(pgSQL), so don't know the current status of the ecosystem.
2. At the end of the day, web backends are just a lot more varied and complex than web frontends. On the technical side, a web frontend is always just bundles of JS, HTML, CSS, that have to be transmitted to the client. And functionally, there's a relatively large set of common things they pretty much all do (routing, serve images, etc.) Therefore, it's relatively simple to build an opinionated framework that can still cover a good number of situations.
By contrast, a "backend" is really a lot of different things (like the four you mention, plus various types of storage and caching), which can use many different languages/technologies, all working together in different ways. It's hard to conceive of a universal "backend" framework that could cover all of that complexity.
3. There are some efforts to do this kind of thing (to some extent). Google's Firebase and AWS Amplify are the two that I think are closest -- they try to give low-configuration generic backend building blocks. (I'm currently using Amplify for a project -- still too early to tell. It also works with Next.js!) There's also platform-as-a-service options like Heroku.
> No, they aren't. On the technical side, a web frontend is always just bundles of JS, HTML, CSS, that have to be transmitted to the client.
First, that's factually untrue; web front-ends can contain a wide array of things beyond those three (WASM, content in formats other than HTML that is read and used by the JS/WASM, etc.)
Second, on a similar level of reductionism, web backends are just bundles of bytes that need to be deployed on servers.
I did not mean to imply that all, or even most backends are more complex than frontends -- only that the problem space of backends is larger and more varied (for typical web use these days, at least.)
And 'sufficiently dynamic web apps still will want a SPA' doesn't make much sense to me because you can just use nextjs in full SPA mode and its just as 'dynamic' as any react app
I really just want a framework that allows me to:
1) Run locally like Next.js's "npm run dev"
2) Do end-to-end unit tests because the framework provides the abstraction layer
3) Deploy to the cloud via push to Github and have it run exactly the same as (1), but do it at scale (deploy to serverless functions, use actual SQS Queues, Eventbridge, etc.)
Of course the core would a developer experience like Vercel, Stripe, etc.
That way instead of learning a new and likely less advanced framework you can use your favorite and likely more mature and well maintained backend framework and just deploy in a minute with caprover, as long as you can dockerize it it should work, you just have to write a single dockerfile ( they also have a way to not write dockerfiles directly and use their abstraction ).
You take advantage from the backed framework you already know with all its advantages and also benefit from Docker's huge community. Their UI is really good to be honest, you can enable and force https in one click and other goodies like that, DigitalOcean also have a preconfigured Ubuntu droplets with caprover preinstalled to make it even smoother.
- an RDS postgres instance with a curated set of DB scripts with auditing baked in
- Lambda/API Gateway based API
- fully implemented with users, roles, groups
- application level authorization
- Cognito for user authentication (sign up or admin created)
- S3/CF for hosting/files
- React frontend
- all in Typescript with a robust type-set; same types for the whole stack
- deployed via CF template along with some custom scripting I have done to tie it all together
It's been a work in progress for some time on the side, but I am now formalizing it. It might seem a bit rough on the edges at first, but it gets the job done, and can more or less be extended into other AWS services as needed. I haven't really received much feedback yet.
It's all open source, you just pay for the AWS resources, and it installs from npm and deploys in about 10 minutes based on how long the DB and CF distribution take to deploy. Here's a sped up install video: https://www.youtube.com/watch?v=b3mzwtIyt9s
And here's the git, https://github.com/keybittech/awayto
I am in the midst of drafting formal documentation, how-tos, and other media that I can share with the community to help make it easier to understand and use. Any feedback is greatly appreciated!
Go Micro (17k stars) https://github.com/asim/go-micro
Micro (10k stars) https://github.com/micro/micro
M3O (1.7k stars) https://m3o.com
1) Ideally the framework is polyglot (Go seems sensible though)
2) I wish they had queues/events that were wired up to functions
3) Not sure if using autoscaling k8s services under the hood as opposed to serverless functions is the right choice
4) A bit too opinionated on DB/Auth (maybe I don't want to use Postgres)
5) With all of the above you could get really great end-to-end integration tests as unit tests that I don't see them taking advantage of
Your thoughts are very much in line with where we're going. We're working on natively supporting queues, pubsub, object storage, etc. Our roadmap is available at https://encore.dev/roadmap which should give you an idea.
We definitely intend on supporting more storage options. We already do provide end-to-end integration testing out of the box that integrates with Go's built-in testing support.
The authentication should be pretty flexible; was there something you were thinking of that makes it too opinionated or inflexible?
Thanks!
This feels like a weird criticism considering Next is React only.
If folks are interested in working on something like this, my email address is in my profile. Don't hesitate to reach out.
You can give us a go at https://dev.new/
We're working on making the project connections a bit better so that generalizable connected services are as trivial to build as stateful monolithic backends in the current platform
Anything else we've missed and I'm happy to sit down with you (or anybody else) and hear what your needs are. Arbitrary evented triggers are coming pretty soon as well as the API so the infrastructure should be fully composable/meta.
P.S We integrate with the lovely lads/lasses/fiends at Vercel :)
If I have to use:
1) Pusher for realtime
2) Supabase for DB
3) Temporal for workflows
4) Vercel / Netlify, etc. for functions / cron jobs
My backend becomes primarily a bunch of stuff glued together, rather than something cohesive like Next.js
I'd do the exact opposite by default, trying to have the most cohesive service, and occasionnaly use some external APIs when I can't do the stuff by myself (eg. Stripe)
I would love a clean Vercel-like abstraction on top of standard cloud primitives (functions, queues, events, workflows, etc.) with everything wired up nicely and focused on developer experience. It just seems like AWS is so configuration heavy that it is ripe for a Vercel-for-backend to emerge.
Does anyone know of an existing open source framework + hosted cloud platform that is a one-stop-shop for writing a production-ready backend in the vein of Next.js + Vercel?