I'm looking forward to see how this impacts existing wifi mesh routers like Eero and Orbi. Hopefully this standard will make good wifi routers more mainstream.
1,624 karma · joined October 17, 2010
Would love for this to land :-)
Did you already use yoga and bindings? I think you might find it inspirational.
Prisma is an evolution of Graphcool Framework. Graphcool Framework is a complete backend as a service that enable you to create a database, configure permissions and write business logic that is deployed to serverless functions.
In contrast, Prisma focuses exclusively on the database aspect and brings many advancements compared to Graphcool.
We have created some nifty open source libraries to bring a lot of the same out-of-the-box experience provided by Graphcool Framework to more traditional GraphQL backend development with Prisma, including GraphQL Bindings that provide smart schema stitching and auto-complete in your editor as seen in the video on https://www.prismagraphql.com/
Prisma incorporates 2 years of learnings from operating Graphcool at scale and writing big applications with GraphQL. I'm super excited to be part of the community that is shaping around GraphQL and happy to answer any questions about GraphQL in general (especially from the backend perspective) or Prisma specifically.
Then you either have a central team responsible for the public GraphQL API. They will typically write a server in Javascript that composes all the microservices. Or alternatively you have multiple product teams that all want separate GraphQL APIs tailored to their use case. They too typically use Javascript for the server.
When multiple languages are involved it turns out to be really useful to be able to use GraphQL SDL as the canonical representation and use code-gen on each stack. This is the use case GraphQL binding is intended for: https://github.com/graphql-binding/graphql-binding
If you need something _now_ you are probably better of looking outisde the GraphQL ecosystem though.
You should also consider what your need is. If you need true offline support (ie, you have an app that needs to fully function for days without internet) then that is a very different scenario from just needing to have a bit of data cached for the duration of a subway ride.
GraphQL Bindings are generated from a GraphQL schema and provides static typing in various languages. Right now code-gen for typescript is supported. Scroll down a bit on https://www.prismagraphql.com/ for a short video demonstrating how this works in practice.
I'm very happy that more projects are exploring code-gen for GraphQL.
- has a very low base cost - scales quickly to thousands of req/s
Operating this on lambda has some significant downsides:
- no request multiplexing - warm up overhead (lambda itself, our service, connections)
As we are operating at large scale we can invest in building infrastructure that supports this with more traditional AWS primitives.
In broad terms our approach is to:
- operate a t2.micro for each tenant - use burst capacity to bridge scale up periods - switch to c5 instances when a cluster reaches higher load.
This is a lot of operational overhead, but because we operate thousands of clusters we can fully automate this.
As a user of Prisma you can consume your database via a GraphQL API over http. This is a great benefit when developing serverless functions as Prisma essentially moves db connection pooling outside your serverless functions.
The switch from REST to GraphQL moves the burden of data fetching from client to server. As GraphQL is dynamic in nature you have to handle any query the frontend might send and can no longer rely on the static shape of a REST API when optimising your data access pattern.
The fundamental issue is that there is a big gap between the GraphQL API you want to expose and the underlying data layer you have available. Sometimes you need to combine data from several underlying databases making it critically important to perform data queries in the right order and in parallel when possible.
Think of Prisma as a GraphQL database query engine that analyses every incoming query in order to generate an optimal execution plan for your underlying databases.
With Prisma we are focusing on the core technology and exposing as much raw database power as possible. We will implement native PostgreSQL support in the future to take advantage of the superior json handling
It was awesome to see how Graphcool enabled so many frontend developers to get started with backend development.
And it has been even more exciting to see these same developers move to a combination of Prisma and GraphQL bindings with relative ease.
The GraphQL ecosystem is maturing to a point where the tools are now easy enough to be used by small dev shops and powerful enough to be used by large enterprises. There was an episode on GraphQL Radio (https://graphqlradio.com/) diving into how IBM build their own library to standardise schema composition. This is a fairly advanced concept, but with GraphQL binding this is now part of day-to-day development for thousands of developers.
To address the money part - Enterprise and on-premise is certainly a thing. We get a lot of requests for custom setups. If you are interested to explore this option, please get in touch!
@LawJolla et al - We have seen tremendous growth in our Cloud business since the launch. Watch out for announcements in this space over the coming months :-)
See my comment higher up about the main difference :-)
The Graphcool Permission system is super interesting because it ads a surprising amount of expressive power to a declarative permission system. We actually brought over the idea to prisma-binding https://www.npmjs.com/package/prisma-binding by including the `exists` query. For now you have to manually perform the check in resolvers, so it is not a complete substitute.
Speaking of permissions in Prisma in general. For now it includes a fairly primitive token based system: You either have full access or no access at all. In the future we will add more fine-grained grants so you can give some users read access to specific types while preventing data mutations for example. The details are still being worked out, and this system will not be as flexible as Permission Queries in Graphcool Framework.
Let me try to clear things up :-)
The Graphcool Framework is a all-in-one framework that combines a GraphQL query engine (now called Prisma), serverless functions and managed hosting (Graphcool Cloud).
Prisma is a major rewrite of the query engine. You can think of Prisma as the query engine powering the Graphcool Framework.
Today Prisma can be used stand alone as a GraphQL database layer in combination with GraphQL Binding. Later we will change the Graphcool Framework to use Prisma as the query engine.
In short - if you like the features of Graphcool Framework, you can keep using it like nothing changed.
I'm sorry you got stuck setting up docker on your local machine. We have put a lot of work into making sure local clusters "just work". It would be a big help if you could start a thread on the forum so we can help identify the issue.
The reason we are using docker to run Prisma locally is that we believe it is super important to have the same environment locally when you develop as when you run in production.
If you are familiar with docker you can follow the guide in the docs to set it all up without relying on the CLI. That should give you a little more transparency into what is going on :-)
Postgraphile is a pretty cool project that was on hn yesterday actually https://news.ycombinator.com/item?id=16150663
PostGraphile and Prisma takes different approaches in that PostGraphile embraces the power of PostgreSQL and encourages you to place business logic in the database.
Prisma on the other hand is a separate piece of infrastructure that you deploy in front of a database to add extra functionality such as realtime subscriptions, rate limiting etc.
If you haven't checked it out yet, then I'd encourage you to take a look at GraphQL bindings and how that allows you to work with your own server for more complex scenarios: https://blog.graph.cool/reusing-composing-graphql-apis-with-...
Prisma is available as a docker image If you are familiar with Docker it should be fairly simple for you to set up a cluster. We also have a tutorial walking you through deploying to Digital Ocean in 20 minutes: https://www.prismagraphql.com/docs/tutorials/cluster-deploym...
There is great interest in supporting multiple kinds of databases and this is something we will actively work on in the coming months.
SQL is a great general purpose data store, but there are certainly cases where you need a more specialised database. In Prisma we introduced some API changes to simplify working with nested data structures. An obvious next step is to use MongoDB for documents while keeping SQL for relational data.
Did you already have a chance to look into the new architecture for Prisma and GraphQL Bindings?
Digital Ocean is trying to move up the stack to compete with AWS, but they still have a long way to go.
I am wondering if anybody is actually using their cloud-like features?
Personally I prefer keeping my database layer as simple as possible - no stored procedures, no queues and certainly no communicating to external systems.
But I still see great value in generating a GraphQL data API and using that as the only way to interact with the database. GraphQL Bindings is a new technology that allows you write a server that acts as an advanced proxy in front of another GraphQL API. It allows you to recompose the schema, and intercept requests for specific queries or mutations.
Using an approach like this you can pass through queries to PostGraphile almost unmodified while taking full control over mutations.
It's early days, but we have a pretty cool setup that generates TypeScript type definitions based on the underlying GraphQL API. And it is all open source :-) https://blog.graph.cool/reusing-composing-graphql-apis-with-...
One of the biggest foot guns when working with ORMs is lazy data loading. This is a feature implemented by most advanced ORMs that allow the developer to pretend that the entire data model is in memory without having to actually fetch all data on every request. The reason this is so dangerous is that you end up passing objects around that other developers then misuse to fetch "just a little more data". Over time this can lead to tens or hundreds of roundtrips to the database for a single request.
GraphQL tackles this issue head on by encouraging the developer to specify all data dependencies up front. Client side tools like Apollo and Relay even help you collect data requirements from multiple related components and construct a minimal covering query. This means that there is only one request, and the underlying query engine has all information available.
I'm pretty excited to bring these same concepts to the server with GraphQL Bindings: https://github.com/graphcool/graphql-binding
In Denmark we have a national system of sirens. They are tested once a year at a specific date and time. In the cold war era they used to test them every Wednesday at noon, but it has been scaled down since then :-)