This looks really cool and I've definitely been feeling this pain. I've been building out a solution for myself on top of docker. What are the advantages of using coasts over docker?
Hey thanks! To be clear it does use docker. It's a docker-in-docker solution.
I think there's a quite a few things:
1) You need a control plane to manage the host-side ports. Docker alone cannot do that, so you're either going to write a docker-compose for your development environment where you hard code dynamic ports into a special docker-compose or you're going to end up writing your own custom control plane.
2) You can preserve your regular Docker setup without needing to alter it around dynamic ports and parallelized runtimes. I like this a lot because I want to know that my docker-compose is an approximation of production.
3) Docker basically leaves you with one type of strategy... docker compose up and docker compose down. With coasts you can decide on different strategies when you switch worktrees on a per service basis.
4) This is sort of back to point 2, but more often than not you want to do things like have some shared services or volumes across parallelized runtimes, Coasts makes that trivial (You can also have multiple coast configs so you can easily create a coast type that has isolated volumes). If you go the pure docker route, you are going to end up having multiple docker-composes for different scenarios that are easily abstracted by coasts.
5) The UI you get out of the box for keeping track of your assigned worktrees is super useful.
6) There's a lot of built in optimizations around switching worktrees in the inner bind mount that you'll have to manually code up yourself.
7) I think the ergonomics are just way better. I know that's kind of a vibesey answer but it was sort of the impetus for making Coasts in the first place.
8) There's a lot of stuff around secrets management that I think Coasts does particularly well but can get cumbersome if you're hand-rolling a docker solution.
It works fine on mac (that's what we developed it on) and it's not nearly as much overhead as I was initially expecting. There's probably some added latency from virtual box but it hasn't been noticeable in our usage.
Thanks for the kind words! We're collecting feedback over the next 1-2 weeks to prioritize the road map.
Is there anything that you would like to see?
A few things that are on our radar though:
- Support for more APIs out of the box. We've implemented a number of APIs that we've submitted for approval (including a bunch of google APIs). They should be added in the next few weeks.
- The ability to add your own API integrations via a simple form if we don't support them (both token based and OAuth APIs).
Long answer: As you may know, Samsung Health doesn't provide a public REST API. We are looking at different ways that we might be able to make that information available through the Google Fit API though (Samsung does allow their app to share data with Google Fit).
Everyone has trouble accepting criticism to some degree or another. I've found that with younger engineers this is some amount of imposter syndrome that can express itself in different ways. One way I've found to break through is to highlight all of the positive things I notice in a PR. Even if it's something that should be expected (eg. "Thanks for writing this test!") the positive re-enforcement helps with confidence and softens the blow when you do point out some areas for improvement.
Could you speak to security of information that I allow Slapdash to access? I'd be very interested in using this, but how do I know the sensitive information that I give you access to is secure?
No much magic here, we use pretty standard protocols and approaches for security.
The data stored is public-key-encrypted (buzzwords: ECIES, Secp256k1, AES256+CTR), and the decryption private keys (per app/user) are available only to the very last and isolated layers (e.g. in particular, right before the search snippet is sent to your browser, or right before the text is tokenized and converted into an inverted index which erases the information about the actual words location in the text). The engineers can’t see the users' data.
App access- and refresh tokens (which we obviously need to send API requests to the apps you connect) are stored the similar way. They’re only decrypted in a separate layer right before requests are sent to remote cloud apps' APIs.
We will publish a comprehensive overview of our approach to security, which I'll link to this thread for posterity. Frankly, we just ran out of time to publish this in time for the launch.
To compliment our architecture, I should mention we also also have strict company policy around general IT security and any type of customer data access. Security is an evergreen problem here.
We are definitely open to a self-hosted solution, but at the moment we have a small team, so we are trying to keep our engineering surface area manageable.
In the near future, we will be offering deployment to an isolated instance. It would be operated by us, but we would be able to provide infrastructure access.
A step after that would be to offer VPC deployment where the updates are applied by the customer and we wouldn't have access to the infrastructure.
I'm building a fitness tracker specifically for rock climbers using RFID in addition to the regular fitness tracker sensors (accelerometer, altimeter, etc). It started as a project to teach me lower level embedded programming (I do web dev for my day job). Since then it's expanded and we're actually testing it at a local rock climbing gym. If you're curious you can see a demo video here https://www.youtube.com/watch?v=6gnEAeMDKt8
reply