Hacker News new | ask | show | jobs
by Herbert2 2746 days ago
Using it for two days now on OSX for a client so I don't have much experience with it. First impressions are ok, the documentation could be better and it's not very googleable as you get a lot of irrelevant hits from normal .NET, MS really should have more creativity when it comes to naming. Problems I've hit which I wouldn't expect to hit in a more mature framework:

* Running EF Core migrations against postgres on startup. I wasn't able to google a solution to this. I hacked around this by deploying an init container with a migrate.sql script but I expect that'll bring me problems later on.

* Let's Encrypt. Found an archived package on GitHub, I expected more maturity.

* Not very easy to ascertain the state of the setup, things need to be registered in a certain order for them to work (UseDefaultFiles & UseStaticFiles f.i.). This would be made easier by me having more experience with the stack or better docs, still a waste of time.

3 comments

You can use FluentMigrator package for database migration. We have used it and it is pretty solid.

https://github.com/fluentmigrator/fluentmigrator/issues

I am curious about your encrytion scenario and why did .Net core fall short.

Thanks for the tip, does FluentMigrator require me to duplicate the table structure in it's DSL or does it have a way to pick up EF Core tables & detect changes?

Re encryption, I was looking for a way to do automatic TLS via https://letsencrypt.org/. Closest I could find was https://github.com/natemcmaster/LetsEncrypt which is archived.

Unfortunately it does not detect DSL changes automatically so yes you will have to copy changes.
What's the common use-case scenario for migration handling in the C# world? I've seen a lot of people doing checks on application startup: Do I have pending migrations? If so, run them. In the Ruby world, checking and running migrations is usually part of the deploy routine, not application startup, and are usually handled by a separate CLI command.
> Not very easy to ascertain the state of the setup, things need to be registered in a certain order for them to work (UseDefaultFiles & UseStaticFiles f.i.).

This point drives me mad. Only after running into errors and reading SO you discover some methods should be called before other. Given how many there is, it's difficult to know if the whole order is done right.

To take the best that it offers, don't forget to use asynchronous calls from the top to the bottom of your code.
Right, it determines ability to scale. For instance, time to time I had a timeout error while connecting to Redis even on low load. After rewriting to async-await the issue has gone.