Replies: 10 comments 41 replies
-
useQuery APIWhich do you prefer? Either way we'll have a codemap that automates the migration from current Blitz. // Option 1 (strongly typed)
const [project] = useQuery.getProject({ id: 1 });
const [createProjectMutation] = useMutation.createProject()
// OR
// Option 2 (also strongly typed)
const [project] = useQuery("getProject", { id: 1 });
const [createProjectMutation] = useMutation('createProject') Option 2 is a little closer to the raw react-query API, but that has a slight downside of adding potential for confusion. Whereas Option 1 is very clearly an abstraction over useQuery. |
Beta Was this translation helpful? Give feedback.
-
Collaborating with tRPCAlex (@KATT), the creator of tRPC made a very kind proposal to work together to bring tRPC inline with our Blitz requirements. Fundamentally it absolutely makes sense try and join forces. tRPC was originally created so that the blitz-style zero-api layer could be used as a standalone library. And now with the new Blitz pivot, we also want our zero-api data layer to be a standalone library. So if we don't join somehow, then users will have to choose and compare between them. Here's the main differences I think we need to resolve. Overall API simplification from what trpc currently has to what I have aboveAlex already mentioned to me that he's very keen on simplifying the API. Aside from client and server differences, currently tRPC on the client as various config options in different places ( Keep our existing resolver api: (
|
Beta Was this translation helpful? Give feedback.
-
Question regarding query and mutation imports. Do I have to explicitly input each query/mutation as an import in the server file? What does one do when they are going to have > 100+ files of these types strewn about within their application? And in multiple directory depths. 👀 |
Beta Was this translation helpful? Give feedback.
-
Would this allow for the possible creation of a rpc sdk generation tool, so that one can create a SDK library to use for a react-native app calling the same service for example? |
Beta Was this translation helpful? Give feedback.
-
I'm just starting to develop a production ready app with the Amazing Blitz. What's is your recommendation: Continue or just move to Nextjs? How much time does you need to develop the Toolkit? Thanks. |
Beta Was this translation helpful? Give feedback.
-
Update Dec 23We are strongly considering keeping the current magical import for queries and mutations (where you import the query/mutation directly into your components). In which case you would not have to import every query and mutation into a single setup file. We can do this with a custom webpack loader instead of babel, so it won't interfere with the Next.js swc compiler. The underlying implementation difference is that currently each resolver is a separate nextjs api route, but the new way would consolidate all into a single nextjs api route. The new way would work out of the box with Vite. And we would ship react-native support at the start too. We would also support a "non magical" way like described in this RFC for alternative uses. As for the tRPC collaboration, Alex and I have had some extensive discussions. As of now it looks like we'll probably use the tRPC core backbone for the network layer, but have our own "developer interface". This will allow us to have the stylistic differences we both care about while not duplicating efforts on the network backbone which is where a lot of the hard work is, especially for things like websockets. |
Beta Was this translation helpful? Give feedback.
-
Hi guys, now you are pivoting toward a reusable toolkit, I'll try to share a bit more about what we have been done in our own framework, Vulcan, because we have many problems in common and also tried to have a framework agnostic approach. At Vulcan we have this kind of setup, for GraphQL:
Packages can be found here: https://github.com/VulcanJS/vulcan-npm So basically we have been having the same objectives, differences lies there:
|
Beta Was this translation helpful? Give feedback.
-
Are there any worries about Next.js or the JS ecosystem in general potentially moving away from webpack? Would it make sense to first ship a "no magic" API and then later ship a compiler assisted API? |
Beta Was this translation helpful? Give feedback.
-
Above first, thanks for your hard work! 1.nextjs + blitz-toolkit + nestjs Personally I want to choose 1. |
Beta Was this translation helpful? Give feedback.
-
Hi @flybayer! 😃 I just stumbled onto this discussion and was very excited! Given the lack of recent activity I presume development of this has stopped? This would be a dream tool! All the pros of writing server code in the client (like blitz already) but in plain next.js and without the potential downsides of RSCs would be epic! |
Beta Was this translation helpful? Give feedback.
-
This is an RFC to discuss the specifics of how the zero API data layer will look and work in the new Blitz toolkit.
Prerequisite: Read [RFC] Important Discussion On Possible Blitz Pivot
Fundamental Design Principles
In the current Blitz framework, there are a ton of small design decisions that together add up to a really special DX that so many avid Blitz users rave about. Many of which are not readily apparent to onlookers or casual users. These have all been battled tested in thousands of production applications, and have proven to significantly increase product shipping velocity, have proven to be scalable to large applications, and have changed the game for hiring. No longer do you have to struggle to hire backend engineers capable of building and maintaining production GraphQL setups. Instead you can hire frontend engineers who can now ship backend code because the Blitz design decisions are intuitive to them and easy to use.
With the battle testing, we also now know which decisions weren't great. But the awesome thing is that almost 100% of the things we should change are internal implementations, not developer facing APIs. In most cases, they were implementations that made it difficult to add features y'all have requested. So this is a chance to fix all that and enable us to ship better, more powerful features.
With that said, the most important principle is to preserve the APIs and DX of current Blitz as much as possible. However, this pivot does present an opportunity to tweak some things if there is sufficient desire from Blitz users to do so.
Preserving the APIs also greatly aids the migration path from current blitz to new blitz toolkit, which is a hugely important to make easy.
New Goals
GET
for queries by default, which enables easy cachingthrow
extra things like Redirects — especially useful in context of Remix.Implementation
Code
Because current Blitz zero-api is enabled through babel plugins and nextjs compiler, there's not much code we can extract and re-use. So we mostly need an entirely new implementation.
Design
(input, ctx) => output
)Query/Mutation File
Add server setup file
Then expose your server in an API route
Add client setup file
Then import from client setup file to use queries/mutations
Your Feedback
Please review and provide any feedback or thoughts you have! I've posted a couple sub-topics below for more discussion regarding API and collaborating with TRPC.
Beta Was this translation helpful? Give feedback.
All reactions