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.
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!
Please do! If nothing else, it's definitely a fun language to learn. We're also setting up a community of folks who are learning Go/Copper. Check the project readme link for the link.
It kinda does but there's a lot of boilerplate that goes in before we actually get to the app logic. And, understandably, there's no structure provided by the Go stdlib.
Once I made many projects with just using stdlib, I started taking common packages out. And Copper is essentially that. I can start writing my app code with minimal setup / boilerplate.
Thank you! ListMonk looks great but I'm not sure what their future plans are so it would be hard to do a fair comparison. For DropList, the plan is to move towards email automation using drip campaigns.
Author here. I work on several projects that require me to stay in touch with the customers and keep them up-to-date on new initiatives that we are taking. I have tried several marketing platforms such as Mailchimp and Sendy. However, they can be really expensive or hard to maintain/set-up.
The goal with DropList is to have an open-source [1] marketing platform that can be easily self-hosted. But, we do provide a hosted version [2] for convenience at a very low cost. Over time, I want to add features for email automation, complex segmentation, and more.
If you have suggestions or any other feedback, please leave comments here.
- No good reason really. I prefer having "app" in the URL and I was already using app.autogradr.com subdomain for an older version. During the migration, I had to keep both of them running so I opted to get the new domain.
- That's a good point about the role. Surprisingly, it is not common for users to switch roles. I had punted this functionality until I would need it but even after a lot of usage, no one has requested for this feature. However, as an instructor you can get the "student" view.
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!