Yeah I ended up just adding to claude.md for it to make a single file summary of the entire vault at any new update. It works fine.
But it would be nice to directly hook it up to a GitHub repo that I can commit and push to. I’m guessing MS won’t let them build that to safe guard their own models and OAI investiment.
At this point Claude so is far ahead in “empathetic understanding” and relational understanding, it’s painful to use GPT for anything but extremely factual content. IMO both Gemini and GPT are now overwhelmingly a failure as general purpose chatbots, while Claude is increasingly resembles what I imagined an AGI system to be.
12x multiple for a Cloud SaaS company is not overpriced typically. I was surprised at this low multiple. Could be due to the current economic situation. And also the licensing changes, lack of product moat contributing in the wrong time.
Usually it's forced on the backend by the frontend team.
Really, it's just more awkward than writing a straight-ahead REST implementation.
Also the error-handling semantics gets pushed to the backend, and the frontend team (who generally doesn't like handling errors) doesn't really know what to do with errors in general...so the UI design team needs to add that sort of error handling to the UI which makes everyone confused because usually there's nothing you can do about errors on the client side.
The error handling issue can be seen with this simple example: you federate 10 API calls, and 9 of them work fine. Do you return partial data? How do you indicate to the front end that there's partial data? What if the data in the 10th call is the one they need in the UI?
This implies that you need yet another state indicator that says "part of the data was returned" (if the destination was a field)...which is different than "that field was empty." And that's at a minimum.
On the performance side, there is definitely the N+1 problem which is solved (partially) by the data loader pattern.
But curious if the benefits vs tradeoffs is in favour of GraphQL?
And have you considered tools like Hasura/Postgraphile that take care of boilerplate CRUD APIs for databases? Then you actually just focus on writing business logic.
I actually don't use GraphQL in my current position, so I don't think to much about it any more. Intresting tools which I might consider in the future(If I have to write GraphQL).
We have written a post[1] on building a real-time chat app with Streaming Subscriptions on Postgres. It gives a quick overview of the architecture used and how you can leverage the API on the client side with AuthZ. There’s a live demo that you all can try out.[2]
Interestingly, there are no breaking changes that were required to be addressed by Hasura GraphQL Engine to support Postgres 15. Hasura is fully compatible with this release, with the potential of adding the MERGE command via the GraphQL API soon.
Excited about the incremental performance improvements and making more secure defaults by revoking CREATE permission for public schema for non-superusers.
MERGE feature is interesting. But specifically on the revoking CREATE permissions for the public (or default) schema, this is a step in the right direction. Some of the defaults in Postgres can be more secure. For example, the first time I use a POSTGRES_PASSWORD to configure a password, changing this password involves more steps than just changing the values of the ENV, because it doesn't take the changed value there after.
Structured logging with JSON is going to improve a lot of debugging, again a great productive change.
Also, any idea when the docker image for Postgres 15 will be available?
Looking at the Alpine docker file(s) for Postgres you might be able to use the one for the release candidate and set en environment variable of PGVERSION=15.0 which should use https://ftp.postgresql.org/pub/source/v15.0/ here.
You would need to figure out what the package name is on Debian (if it even exists yet?) it's currently set to ENV PG_VERSION 15~rc2-1.pgdg110+1
Hasura connects to databases and all your other APIs to give a unified GraphQL API (and REST API, if you configure it).
This takes care of your CRUD APIs portion of building your app. With declarative Access Control Rules, you get powerful Authorization. IMO, these two should take care of 70% of your application code that you typically end up writing. The remaining will be custom business logic that you can write in any language or framework of choice and connect it to Hasura.
There’s of course more with the cloud offering to give you caching, rate limiting and monitoring in production. Hasura doesn’t host your database, it just needs the db connection string to get started.
We're very excited to launch GraphQL joins - a way for folks with existing investments in GraphQL to join data across GraphQL and non GraphQL sources. A few key points:
- Join data across new or existing GraphQL services: Your own GraphQL services or GraphQL vendor APIs (eg: Github)
- Join GraphQL services with other non-GraphQL services: Join data in your GraphQL Server with data in your databases (eg: Postgres, Timescale, Yugabyte with GraphQL servers)
- Uses native GraphQL with no changes to the GraphQL specification: No upstream changes are required to the GraphQL service
- Powered by semantic configuration - no custom code required.
Claude Code works though. But now I can’t share this with non-technical users