Thanks for mentioning Graphile Migrate. Migrations are often the biggest issue people have with something like PostgREST and PostGraphile; I’ve used a lot of the various migration tools and Graphile Migrate is the seed of my vision for a much more compelling migration story for everyone in the PostgreSQL community (especially people who don’t mind writing SQL but find the current up/down pattern too verbose/clunky as I do). There’s lots more to come, so make sure you follow the project if you’re interested.
Have you tried the PostGraphile Starter? It’s not officially released yet but you can find out more in the Discord chat #announcements channel. https://discord.gg/graphile
I wouldn't let that sway you too much; the main reason for the performance difference is that PostgREST builds the JSON response in the database and then pipes that through to the user directly (at least that's my understanding). PostGraphile OTOH parses the JSON from the database and feeds it through the rest of your GraphQL schema, allowing data to be mixed in from your custom fields which might fetch from microservices or external services such as Stripe, or just perform additional calculations in application-land, and finally serialises the resulting data to send it to the end user. Despite this significantly greater flexibility and power requiring all this additional work, PostGraphile achieves very solid performance.
No problem; I saw 8base at one of the GraphQL conferences, looks cool. I agree: PostGraphile is intended for people who want to control their own servers (be that via serverless, containers, Heroku, or traditional servers).
PostGraphile is not an ORM, it’s a client-facing GraphQL API designed to be consumed directly from your frontend applications (web apps, mobile apps, etc). This is why it has such powerful customisation and extension features so you can use it to build the GraphQL API you want.
I suspect many of these concerns were with PostgreSQL 9.5 and 9.6 where RLS did indeed have many performance issues. PG 10 fixed a large number of these issues, and PG11 even more. I would recommend re-evaluating RLS performance on these latest PostgreSQL versions.
It feels a bit misleading to say PostGraphile is "GraphQL-as-a-Service". Typically XaaS is used when there's an external service (normally hosted elsewhere) that provides this functionality; whereas PostGraphile is 100% self-hosted, we do not even have a hosted offering. Further, PostGraphile is more of a framework for building a GraphQL API than a separate service you run - since it's pure JS (well, TypeScript) a decent portion of our users mount PostGraphile directly into their Express or Koa applications and deeply integrate it, including customising and extending it via plugins. It's much more of a library/framework than an "-as-a-service". (I'm the PostGraphile maintainer.)
I’m sorry you feel that way; I use PostGraphile with external APIs frequently, using makeExtendSchemaPlugin to easily add more types and resolvers to my GraphQL schema. Maybe you could go into more detail on the issues you’ve faced here so I can improve the project?
There’s a bit of a chicken and egg problem with that; basically you’re requiring someone to build and grow the community for free for years until it gets “big and crucial” before paying them, by which time they may well have burned out and moved on.
I think if the software brings you value, you should return some of that value to support ongoing development - at the end of the day you’re going to benefit from the software you depend on being better developed. It’s incredible to me that people don’t support the OSS they use and then spend huge resources switching to a different vendor (e.g. PostgreSQL to MySQL) for something that could have been avoided if they were supporting the OSS from the first place. Supporting OSS is almost an insurance policy against having to rewrite/migrate.
PostGraphile is built on Graphile Engine which is completely backend-independent (like GraphQL itself). This is what we use in PostGraphile for the "look-ahead" functionality, allowing you to build a database/API/backend query that represents a full GraphQL query as one action. You can read more about it here, though it's currently not as well documented as PostGraphile itself. https://www.graphile.org/graphile-build/
Great questions! You're right with number 1: RBAC + RLS (+ custom mutation functions if you need them). For number 2, the solution is currently naive composition of SQL fragments, CTEs, and trusting PostgreSQL to find optimal solutions to admittedly quite complex queries, but this is just the initial implementation. I can confirm that v4 is already significantly faster than v3 at complex queries, but there's still a lot of optimisations left to throw at it (e.g. not converting everything to JSON in the database (which seems to be very expensive), and instead passing down the raw types that PostgreSQL can handle in a significantly more performant manner), and that's before we even get around to writing a query engine that can perform query transforms and optimisations. I hope that PostGraphile can already give better performance than a traditional naive GraphQL SQL + DataLoader solution, but I'm not concentrating on perf right now - correctness first (and tests to back it up), THEN perf optimisations :)
From my chat with graph.cool the other day it seems like graphql-bindings would be a very thin wrapper that also can be auto-generated from a GraphQL schema (e.g. PostGraphile), so there shouldn't be too much additional complexity, and I don't think there's any major reasons they couldn't run in literally the same Node.js process. DISCLAIMER: I've not got around to trying this yet.
You should consider talking to Johannes Schickling of graph.cool; they seem to be very interested in that sort of thing and they've got some really cool open source going on right now. Johannes is a really nice person - I'd definitely recommend you have a chat.
Yeah, renaming things is always painful. We're renaming the project because "GraphQL" is owned by Facebook and we don't want any trademark disputes down the line. We've mentioned the rename in a number of places but I suppose we could always add it to more places - where would you suggest?
It's worth noting that the entire GraphQL schema generation in v4 is a ground-up re-write (that's where the "graphile" comes from - it was originally a separate project), we've kept the top level APIs from v3 though (e.g. the web layer). This has enabled the performance improvements, plugin system, and greater customisability.
Hi, PostGraphile maintainer here. Excellent points! This is actually where the powerful GraphQL ecosystem comes in really handy - with functionality such as GraphQL schema stitching (e.g. graphql-weaver) you can use something like PostGraphile to rapidly build your MVP and easily augment it, extend it or combine it with other GraphQL schemas to build exactly what you need. You could also use something like graphql-binding from graph.cool to build your dream GraphQL schema, and then just call out to PostGraphile under the hood - there's no need to expose the PostGraphile schema directly to the public if you don't want to!
With version 4 of PostGraphile I've been really concentrating on the ways that people might want to customise or extend the system, whilst also giving it a welcome speed boost (and reduced memory usage). We're pretty close to a v4 beta now :)
This couldn't have happened at a better time for the apps we're working on in the coming months! Congratulations on launching and all the best for the future :)
I'm inclined to believe this is legitimate research - looking up the IP address seems to check out, it's at least assigned to "Technische Universitaet Muenchen". First probe I've seen that truthfully declares itself as non-threatening.
I have results - I'm impressed with the quality of the output - especially that errors aren't cascaded! I would spend more time looking at it now but unfortunately it takes a while to load each screenshot currently. I'll check back tomorrow when your servers have had time to recover.
Do you have plans to support different (user configurable) window sizes? My site uses media queries to differ the appearance based on browser size, which means the older IEs can't help but fail to look the same as modern browsers.
I think they might be suffering heavy load; I don't think waiting an hour is an acceptable delay for web dev - it would make for a very slow iteration loop!
> There are 68 other webpages queued before this request.
> Your request should be completed in about 1 hour.
This was my fault - I had to abort the server updates to go deal with my unexpectedly and violently sick 1 year old son. By the time I was free to go back to updating the servers I was too tired and decided it would be better to wait until morning - after all the iTunes page linked from the "Buy Now" button explains that the app is being discontinued.
The app will exist in your iTunes backup(s) if you've sync'd since buying it, and on your device(s) unless you delete it, so users shouldn't have to worry too much about accidental deletion. If they delete it from both places then I'd suggest they probably don't want it back anyway.
FitFu allows you to do a lot of stuff without even signing up for a "FitFu online" account, and even once you have signed up we built it to deal well with being offline or on a flaky internet connection. Effectively when we "turn off" the servers the app should just treat it as if it is offline and continue to function normally but without the network features working. I think this is generally a good approach to take on mobile.