better-sqlite3
pothos
Our great sponsors
better-sqlite3 | pothos | |
---|---|---|
28 | 24 | |
4,942 | 2,209 | |
3.0% | - | |
8.0 | 9.3 | |
12 days ago | 14 days ago | |
C++ | TypeScript | |
MIT License | ISC License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
better-sqlite3
- From Frontend to Backend
-
Build A Full-Stack Typescript Application with Nuxt and tRPC
In the second video of the series, we are separating routers and adding SQLite, Better SQLite 3, Database to the application to show access to context for performing a simple query and mutation.
-
How practicle is it to have a textfile based database with an SQLite API?
If I were charged with this task I'd probably take an actual SQLite DB and write methods to parse data from text files, then process it within SQLite, and serialize it back to the text file when an API method is called or after each processing step. A fresh DB engine, fully re-implemented to match SQLite's API is insane unless you're a prodigy or have a sizable team and will come with numerous downsides. I can recommend https://github.com/WiseLibs/better-sqlite3 and https://github.com/loveencounterflow/dbay
- VS Code as a dependency for an NPM module
-
Show HN: Doculite – Use SQLite Like Firestore
better-sqlite3 is orders of magnitude faster than the async SQLite bindings. We found this to be true when testing SQLite options for Notion's desktop app anyways.
https://github.com/WiseLibs/better-sqlite3#why-should-i-use-...
Why do you have async reads and writes? There's no client-server setup here, using async / await just introduces pointless waiting.
-
Drizzle ORM, SQLite and Nuxt JS - Getting Started
Better SQLite is a wrapper around the SQLite database engine that provides a number of improvements over the standard SQLite API. One of those benefits is type safety, Better SQLite uses TypeScript to provide type safety for queries, which can help to prevent errors.
-
I Migrated from a Postgres Cluster to Distributed SQLite with LiteFS
Kent's recommended NodeJS module, `better-sqlite3`, has some very nifty features including the creation of JavaScript user-defined functions[0] that (if I understand this right) can be called from SQLite. Combined with TRIGGERs, I wonder if it might fire a function within the app when an UPDATE/INSERT happens from a different process? (This is me wondering out loud, I don't actually know.)
I also recommend checking out Replicache[1] and alternatives, which may be a better way to handle the networking and database replication so that it doesn't rely on the underlying DB.
[0] https://github.com/WiseLibs/better-sqlite3/blob/HEAD/docs/ap...
- Flyweight: An ORM for SQLite
-
Fly.io Buys Litestream
Best option for SQlite with node is this.
https://github.com/JoshuaWise/better-sqlite3
He's all over the issues section, and seems very knowledgeable about how SQLite works.
pothos
-
Ask HN: What would be your stack if you are building an MVP today?
- tRPC
But I'd likely throw out Clerk a cheaper option:
- Supertokens, and also since Supertokens is easy (lots of enthusiastic reports about it), has a managed solution (which is cheaper than the alternatives), is secure and scalable (rotating refresh tokens with JWTs), open source, has magic links, and the architecture of Supertokens would allow me to simply and quickly eject to self-hosting it if/when I'd eventually need to (if the app ever reaches mass-market scale).
And I might throw out tRPC for the equivalent GraphQL experience (esp. if business strategy dictates I need a 3rd party API):
- GQty.dev on the client, for inferred queries/mutations. For rapid dev speed. Simple code example: https://gqty.dev/docs/intro Then move to URQL or Relay at scale, or just skip GQty and go with URQL from the start (if scalability trumps dev speed).
- Pothos http://pothos-graphql.dev on the server, for auto building the schema from your TS code (aka. code-first). Better than Nexus (e.g. Max Stoiber moved from Nexus to Pothos on his Bedrock starter template because Pothos is best in class: https://bedrock.mxstbr.com/tools/pothos/ ).
And I might throw out NextJS (Webpack) for the equivalent experience in Vite:
- vite-plugin-ssr, since both architectural control (libraries > frameworks) and Vite rocks. I'd likely then have to make solito-vite https://github.com/nandorojo/solito/discussions/157 to have a unified navigation between React Native and Web, but Solito is allegely tiny, so recreating it should be doable.
(If doing all of these replacements, maybe starting from scratch would be easier than modifying create-universal-app ... That said, I think if someone made a starter repo with the above choices it would be a real killer!)
Then I'd also likely use:
- Vercel (and try their Edge Functions, for a serverless sweet v8 isolates experience without slow cold starts), or maybe Cloudflare Workers (cheaper, slightly more hassle?) for hosting.
- Planetscale or Supabase for the DB. (Not brave enough to try EdgeDB or SurrealDB just yet, though EdgeDB is close..) Unless I had a specific use case where a more specialized/optimized DB would make sense.
This stack should stick even post-MVP, as it's not only optimized for a solo developer but for scalability.
-
Real World Rust Backend For Web APIs (GraphQL / REST)
Have you used Pothos? It's a way to make GraphQL schemas in TypeScript, in a type-safe way. So the creator of Prisma Client Rust is thinking about making a Pothos-style API based on the t builder pattern:
-
What to use with Apollo Server v4 to achieve type-safety?
I would recommend Pothos (https://pothos-graphql.dev/) as a more modern alternative to typegraphql or nexus.
-
Apollo Layoffs
Depends on language, I've build GraphQL servers in a few, though mostly JavaScript and Python. For Python I used to use Graphene, these days I use Strawberry.
For JavaScript, I originally used graphql-js and express-graphql, as these were the original libraries and I was a literal day 1 adopter. All the libraries are essentially just wrappers around graphql-js, so it's still viable to use directly. But for schema-building I now use Pothos (https://pothos-graphql.dev/), I'd probably use graphql-helix as the http layer (https://github.com/contra/graphql-helix).
-
Achieving end-to-end type safety in a modern JS GraphQL stack
Pothos is a breeze of fresh air when it comes to building GraphQL APIs. It is a library that lets you write code-first GraphQL APIs with an emphasis on pluggability and type safety. And it has an awesome Prisma integration! (I am genuinely excited about this one, it makes my life so much easier.)
-
How to Build a Type-safe GraphQL API using Pothos and Kysely
In today's article we are going to create a GraphQL api using the Koa framework together with the GraphQL Yoga library and Pothos. In addition, we will use Kysely, which is a query builder entirely written in TypeScript.
-
Extreme Explorations of TypeScript's Type System
If you're a GraphQL developer, Pothos is the best example - all your user-defined types just fits in it like a glove 99% of the time. It definitely makes the most use of TS generics.
(I'm a bit sleepy, so this is the main one I can think of at the moment that I really enjoy using.)
-
Replacing Nexus
My favorites are Pothos and gqtx. In terms of documentation and adoption Pothos definitely wins over gqtx. You might also want to check out the "I'm struggling to find proper Graphql Stack" Reddit thread.
-
Fullstack demo app with GraphQL, Typescript, React, and Prisma 🚀. It demonstrates how to get type safety across the entire stack with a great developer experience. Use it for inspiration or suggest improvements 💡
If you are interested in good type-safety using a code-first approach, check out https://pothos-graphql.dev/. It has a Prisma plugin that makes building type-safe graphql schemas backed by Prisma really easy, can solve a lot of hard optimization problems automatically
With https://pothos-graphql.dev/ you can skip the code generation part. That's cool. I'll check
What are some alternatives?
nexus - Code-First, Type-Safe, GraphQL Schema Construction
sveltekit-prisma - A sample repository to show how SvelteKit and Prisma work together.
graphql-upload - Middleware and an Upload scalar to add support for GraphQL multipart requests (file uploads via queries and mutations) to various Node.js GraphQL servers.
Prisma - Next-generation ORM for Node.js & TypeScript | PostgreSQL, MySQL, MariaDB, SQL Server, SQLite, MongoDB and CockroachDB
TypeGraphQL - Create GraphQL schema and resolvers with TypeScript, using classes and decorators!
graphql-ws - Coherent, zero-dependency, lazy, simple, GraphQL over WebSocket Protocol compliant server and client.
graphql-helix - A highly evolved GraphQL HTTP Server 🧬
SQLitePlus - A modern C++ header only SQLite3 wrapper
dqlite - Embeddable, replicated and fault-tolerant SQL engine.
node-sqlite3 - SQLite3 bindings for Node.js
gqtx - Code-first Typescript GraphQL Server without codegen or metaprogramming