[HN Gopher] Future of Blitz
___________________________________________________________________
Future of Blitz
Author : h3mb3
Score : 64 points
Date : 2022-04-03 13:54 UTC (9 hours ago)
(HTM) web link (blitzjs.com)
(TXT) w3m dump (blitzjs.com)
| vosper wrote:
| How will the new model for Blitz compare to tRPC? That's a way to
| get a zero-API setup into a variety of frameworks, including
| Next.
|
| https://trpc.io/
| teaearlgraycold wrote:
| Huh - interesting. I built something similar at work. I didn't
| do a perfect job - you need to manually write in an endpoint
| spec that points to each controller method. For example:
| /** * Add new survey answer. */ //
| prettier-ignore export type AddSurveyAnswer =
| PostEndpoint<`/survey/survey-answer/${string}`, never,
| Validators.SurveyAnswerBody, ResponseDataType<typeof
| SurveyController, "addSurveyAnswer">>;
|
| But really the only duplicated information is the HTTP verb and
| the path. And those won't change very often - if at all.
|
| Then in the front end you import the file containing all of the
| endpoint types: import * as API from "@copy-
| ai/endpoints";
|
| And you're good to make requests: const
| response = await request<API.AddSurveyAnswer>({ url:
| `/survey/survey-answer/${questionId}`, method:
| "post", data: surveyAnswerBody, });
|
| You might wonder - why are you making me retype the URL/method?
| You don't really have to. Your editor will auto-fill that as
| the method can be extracted from the endpoint type as the type
| "post". Not a string - "post". Same for the path, but we use
| parameterized string types.
|
| There's no magic here. What's happening is pretty transparent
| to the programmer. We just tuck away the PostEndpoint etc.
| types as those don't ever need to get changed. You can even
| easily YOLO an API request by passing in the any type.
| flybayer wrote:
| It'll be similar. Same result, but very different DX flavor.
|
| Also, new Blitz includes a plugin system, that allows you to
| easily integrate multiple modules, for example auth and RPC and
| have them work together seamlessly. And have things just work
| like you'd expect, such as query cache being deleted on log
| out, and queries refetched on log in.
| DenseComet wrote:
| Next pushes towards serverless functions and API routes that I
| didn't really enjoy using for more than just a trivial endpoint.
| Blitz is currently built on top of Next so this same issue came
| up, and its value proposition is really only there if you use
| Next.
|
| I'm looking forward to this change and using Blitz again, as the
| frontend experience was super nice.
| leerob wrote:
| > Next pushes towards serverless functions and API routes that
| I didn't really enjoy using for more than just a trivial
| endpoint.
|
| By default (through `next start`) Next.js uses a Node.js
| server. You don't need to use Next.js serverless:
| https://nextjs.org/docs/deployment#self-hosting
|
| Most large applications don't use API Routes for large
| workloads. These teams likely have a completely separate
| backend/API, and Next.js is the connecting piece for their
| frontend. For smaller teams, or solo devs, it's more common to
| see their entire backend built with API Routes (most commonly
| used with something like Prisma):
| https://github.com/vercel/nextjs-subscription-payments
| chrisweekly wrote:
| Hmm. IME, there are significant benefits to a BFF (Backend
| For Frontend), ie Next.js /api routes, even (or especially?)
| in the presence of a separate external API.
| DenseComet wrote:
| I should've phrased it as all in on Next really. I really
| like Vercel and Next.js serverless for hosting, and I've
| usually put APIs on a subdomain. The issue is that then using
| Blitz for authentication and rpc layer becomes very hard to
| do.
| [deleted]
| eurasiantiger wrote:
| I guess this is nice for small projects, but for larger ones, the
| "zero-API" model seems to prevent team member specialization and
| force everyone into full-stack mode. Why does the frontend dev
| need to know database internals?
| flybayer wrote:
| The zero-API model doesn't prevent specialization at all. You
| can add as many distinct domain layers as you want with
| different teams responsible for different layers.
| h3mb3 wrote:
| > for larger ones, the "zero-API" model seems to prevent team
| member specialization and force everyone into full-stack mode.
|
| What is "full-stack mode" specifically? Do you mean the fact
| that each dev needs to run all parts of the application
| locally? You'd want that for most small and medium size web
| projects anyway, even if it e.g. consisted of stricly separated
| SPA and REST backend parts.
|
| With very large projects/teams there are obviously challenges.
| My gut feeling is that a project started with a framework like
| Blitz would probably naturally evolve into some kind of a
| monorepo, which of course comes with both strengths and
| challenges. If you get that far though it'd seem to me that the
| full-stack architecture worked really well for the problem.
| jmtucu wrote:
| Just go with Remix of you don't want to use Next, is more
| reliable than Blitz.
| flybayer wrote:
| What reliability issues did you have with Blitz?
| FractalHQ wrote:
| SvelteKit is way too good- anything React based feels like too
| much of a downgrade.
| cercatrova wrote:
| Then you'd have to use Svelte which not many organizations
| will, as React is more mature and Svelte is newer. Perhaps in
| a few years that will change but IMO moving to SvelteKit is
| orthogonal, most who are currently using React will want to
| continue using React based frameworks.
| uxcolumbo wrote:
| I'm not familiar with SvelteKit.
|
| Can you provide more details about this? In what way is it a
| downgrade?
| samuelstros wrote:
| I played around with Next.js and SvelteKit. I don't recall
| the specific "that's a down/upgrade" but I switched to
| SvelteKit because "it just works". HMR, more or less plain
| HTML, (Tailwind) CSS and JS. Developing with Svelte(Kit)
| feels, and probably is faster than NextJS/React.
|
| The only downside are missing UI libraries like RadixUI.
| Tried out everything and just "wasted" 2 weeks to build a
| component library on top of TailwindCSS inspired by
| Material UI.
| hanifvirani wrote:
| Relevant discussion about the pivot here:
| https://github.com/blitz-js/blitz/discussions/3075
| teaearlgraycold wrote:
| I don't like the pattern of making frameworks _less_ opinionated.
| I had hoped to use Blitz in the future but this pivot will
| undoubtably increase the complexity of the internals. Meaning
| more bugs. More hassle. Somewhere inside there is now a system to
| multiplex between different 3rd party frameworks. What they
| should have done is double down. Rails is one of the most popular
| and longest lasting modern frameworks for a reason.
| flybayer wrote:
| Blitz is not becoming less opinionated. It's just the
| implementation that is changing.
|
| The internals are significantly less complex now. Before, Blitz
| was a fork of Next.js, and dealing with that was a nightmare.
| Contributions dropped off significantly because of that.
|
| Now features are nicely packaged and isolated. Much easier to
| reason about and contribute too.
| teaearlgraycold wrote:
| Forking NextJS does sound like a huge hassle to maintain.
| Having a bunch of separated facade packages with some 1st
| party additional functionality is how I'd do it, too. But
| also allowing for multiple back-ends increases the breadth of
| the code base and in places where one package supports
| multiple back-ends you get increased complexity.
| voat wrote:
| I really enjoyed using blitz for a project.
|
| But I'm tired of the react ecosystem, and I was disappointed I
| had to give up Blitz's features.
|
| But thanks to the pivot, I'm excited to use blitz-auth and their
| Prisma codegen with other projects.
| uxcolumbo wrote:
| Why are you tired of the React ecosystem?
| 0des wrote:
| Needless complexity, heavy weight, high cognitive load if
| you're doing it right (most people still don't use hooks) and
| bottom line holy shit its just frontend, how did we get to
| this point?
| emteycz wrote:
| To what point? It's still better than doing WPF apps and
| comparable to making QML apps. There's no magic sauce that
| makes frontend easy.
|
| The complexity of web pages has increased. Development is
| not harder. We're making complex apps and not just styled
| documents now. What you made 10 years ago is much easier to
| do today.
| tmp_anon_22 wrote:
| Presentational logic is hard, and while each ecosystem
| has settled into an all-rightish presentational UI (i.e.
| React, UI kit) - we still haven't figured out how to pair
| it with state in a way that doesn't require a massive
| amount of duplicative effort.
|
| I'm really hoping for some kind of Rust/WebAssembly kit
| for write-once manage-state everywhere bundles that you
| can deploy to native presentational applications on every
| platform. Kind of like grpc but also tying in
| authentication and intuitive hooks into component logic.
| jimbob45 wrote:
| What do you have against WPF? They were really onto
| something with trying to remake HTML into an extensible
| language of their own.
|
| Hacking together HTML today with React, Angular, and
| VueJS just seems like no one wants to admit that HTML
| needs to be rebuilt and JS deserves to be replaced.
| 0des wrote:
| Cancer is still better than dying
___________________________________________________________________
(page generated 2022-04-03 23:01 UTC)