This is a much better explanation of what it does than captcha where I expect "proof-of-human". A PoW based rate-limiter is a really interesting idea! Usually, the challenge with unauthenticated endpoints (ex. signups) is that the server has to do more work (db queries) than the client (make an http request) so it is really easy for the client to bring the server down. With PoW, we're essentially flipping that model where the client has to do more work than the server. Good work!
Thank you, so much to do in this space!
Bud looks great and I see we share many common goals. The dependency injection piece looks interesting. Did you build it custom or integrated an existing solution?
I think that remains a very valid use case. In Copper, you can create one of those with the CLI. For example `copper create -frontend=vite:react github.com/nasa/starship` will create a react app with a JSON backed API ready to go
This is a good observation. One trend I'm noticing is that the "old way" (PHP, Rails, etc.) of doing things is making a comeback. Go is very well positioned for this but lacks the frameworks.
I'm hoping to add something like Phoenix to Copper. It should help with the "heavily API only side" problem. I've already added integrations for Tailwind and added some utilities on top of the templating (going to add more) to fix the lack of good templating.
Go and Java can never use the same framework patterns as Python/Php/Elixir/Ruby/JS because they are not dynamic enough. The Rails-style request mapped dispatching into active record ORM pattern requires a lot of flexibility on the host language side. For Go and Java, you basically end up with code generation or reflection, and the latter is a killer for performance. On the other hand, the performance of Go and Java is better by several orders of magnitude.
Models change pretty slowly, so codegen is a good solution! Ent uses codegen for its query API which looks pretty nice: https://entgo.io/docs/tutorial-todo-crud
I’m considering writing a Typescript clone of Ent with codegen powered by Typescript types. I like codegen over dynamic magic because the runtime behavior is often easier to understand. In Rails, I need to traverse a lot of space in Pry’s debugger mode to figure out WTF is happening. I would much rather have codegen.
Reflection is killer for performance because it brings Java/Go down to the level of a JIT-less language like Python (and ORMs aren't too kind to JITs in e.g. Ruby/JS either). The problem with reflection in Go/Java is mostly that it's hard to read, since the reflection-ful APIs are hosted rather than native syntax.
Agree reflection has (often big) trade offs but its not as bad as it was years ago, especially if its used during construct time rather than runtime, if you combine it with runtime caches you still get the benefits imo
ha, add me to that list :) I think it's fine if CLIs are optional and I've tried to do that with Copper. Of course, your initial setup will be longer without scaffolding so it's not a great first time developer experience
Code generation is an awesome alternate, I'm more familiar with sqlc.dev. They're doing some really interesting work.
My goal with Copper is to provide out-of-the-box integrations with popular solutions to various problems. For now, I picked GORM but I definitely see adding support for other tools.
Oh that's fun! In my demo video [1], I build a (minimal) HN clone so hopefully that answers your question in detail.
But the tldr is - you'll need a lot more than just templating for a production ready app. To name a few things - server, storage, migrations, logging, configs. IMO there's a huge benefit in having a batteries included toolkit that stays close to the stdlib - so you can totally keep your templates as is!
This is a much better explanation of what it does than captcha where I expect "proof-of-human". A PoW based rate-limiter is a really interesting idea! Usually, the challenge with unauthenticated endpoints (ex. signups) is that the server has to do more work (db queries) than the client (make an http request) so it is really easy for the client to bring the server down. With PoW, we're essentially flipping that model where the client has to do more work than the server. Good work!