If we rewrite our backend for better performance, what will we use?
Backend v2
9
600
resolved Oct 6
ResolvedN/A
1.2%
Firestore
2%
Vercel Serverless Functions
1.1%
Supabase Database
0.7%
Supabase Edge Functions
0.7%
Firebase Cloud Functions
1.4%
Planetscale
48%
Prisma
25%
Postgresql
0.8%
Remix https://remix.run/
0.3%
Astro https://astro.build/
4%
GraphQL / Apollo server
1.8%
Nest.js
0.3%
Blitz
0.3%
SolidJS https://www.solidjs.com/
0.3%
tRPC
1.2%
Redis
0.0%
Svelte https://svelte.dev/
0.5%
PostGraphile
0.7%
Zapatos https://jawj.github.io/zapatos/
Kind of a continuation of https://manifold.markets/Austin/what-database-will-manifold-be-prim . Conditional on us starting on a more performant (eg 2x speed improvement?) implementation of trading, what will that be built on? If the condition is met, will resolve to my subjective assessment of how important each piece of the backend is. If I were to resolve it today, I'd put it at 60% Firestore, 30% Firebase Cloud Functions, 10% Vercel Serverless Functions (but happy to hear arguments for other weights) Some context: [James] One thing Marshall and I were discussing last week was that we might want to migrate the trading system first to another DB and then run that side-by-side with firebase before migrating everything else I still think we would prefer to prioritize getting the mechanisms right for our different market types, e.g. limit orders, numeric, fixed multiple choice and free response markets But another idea would be to build the new Free Response directly on the other db [Marshall] so maybe 1. get limit orders in 2. say that binary markets are basically "done" and start prototyping binary markets on fast DB [Austin] incidentally, I would strongly want Backend v2 to support txns out-of-the-box uh a globally queryable table of every movement of any token (M$, shares, NFTs, etc) between any two parties (users, smart contracts, charities, bank of manifold) which is the ultimate source-of-truth and then also can be used to reconstruct the full history of Manifold Jul 1, 2:37pm: Resolves to N/A if we haven't chosen a path forward by market close time
Get แน€200 play money

Related questions

18 Comments
40 Trades
Sort by:
answered
Prisma
bought แน€50
Betting more of this as I realise it would solve a lot of your problems. Plus it's database agnostic, so very flexible
answered
Svelte https://svelte.dev/
For all I love Svelte, I think changing the whole language is a little excessive (and I am unsure how production ready sveltekit is)
answered
GraphQL / Apollo server
bought แน€100
@JoyVoid +1 for graphql, I'm very used to it after working at Meta, and not having to create new endpoints for every little thing really speed things up.
answered
GraphQL / Apollo server
Actually, Nest has its own Graphql interface. Editing this to "GraphQL" for frontend-backend interaction
answered
tRPC
https://trpc.io/
answered
tRPC
bought แน€1
Since Manifold relies on typescript, it's the easiest way to share types directly between client and server without schemas and code generation.
answered
SolidJS https://www.solidjs.com/
bought แน€1
React-like framework with nicer syntax/bindings for truly reactive code. No more useEffect dependencies! Solid : React :: Svelte : Vue. https://www.youtube.com/watch?v=hw3Bx5vxKl0 Its metaframework (NextJS equivalent) is SolidStart https://docs.solidjs.com/start/getting-started/what-is-solidstart
answered
Astro https://astro.build/
Seems more aimed at the static site generation. Progressive enhancement, mostly renders to html, with js components as necessary (islands/archipelago framing). Notably - allows mixing of different frameworks (React + Vue + Svelte all at once!);
answered
Blitz
Aims to be Ruby on Rails but for React (convention over configuration); prioritizes developer experience heavily; cuts out both Rest and GraphQL somehow. Vercel : NextJS :: https://www.flightcontrol.dev/ :: Blitz
answered
Remix https://remix.run/
Remix is a NextJS alternative with Nested Routes, faster parallel page loading, good error handling, emphasizing stuff happening on the server to reduce payload sent over the wire.
answered
Blitz
bought แน€1
https://alpha.blitzjs.com/ Still pretty early on, maybe in another year?
answered
Remix https://remix.run/
See comparison to NextJS: https://remix.run/blog/remix-vs-next
answered
Nest.js
bought แน€1
(Fairly easy to port next from it)
answered
GraphQL / Apollo server
bought แน€10
Having a REST API can really slows things down/make things bulky performance-wise
answered
Prisma
@Austin I've found it interfaces awesomely with Postgres. But it's mostly agnostic with respect to how you store data, it's basically another layer of API between backend and the database. I've already praised the merits of GraphQL for backend API, so most of them also applies here :D ... Having a strong type system really is awesome
answered
Astro https://astro.build/
bought แน€1
Warning: this might just be me listing out JS stuff that looks cool
Remix https://remix.run/
answered
Prisma
@JoyVoid This one is pretty interesting to me! Looking through https://www.prisma.io/blog/graphql-vs-firebase-496498546142 , which makes good arguments that Firebase isn't the best fit moving forward for us

Related in Backend v2

See more Backend v2 questions

More related questions