I have a question about going from DB first to model first. I created all my tables, relations, etc in my db, including letting the auth mix create the 3 auth tables, app_user, auth_user_details, etc. I now tried to “eject” like it shows in the docs to be model first. But it does not create the db or make any of the changes that I have made in my Types/Models.cs class with all my pocos. Is it supposed to do this, or am I supposed to run the x tool everytime there is a db change and then move the models from the dtos.cs to Models.cs. I had to go through and create all the relationships and constraints by hand, but if I have to run the x tool to create the dtos.cs class everytime there is a db change, then I would have to recreate these constraints by hand everytime as well. Seems like I’m missing something somewhere.
I see how there is a check to see if a db column exists in a table or not, is that more along the lines of what I’m supposed to with the db changes? Is use
using var db = dbFactory.Open();
if (!db.ColumnExists<Schedules>(x => x.TreatmentId))
db.AddColumn<Schedules>(x => x.TreatmentId);
I just see how auth is able to create the schema, db, tables, etc but can’t get my tables to do the same. Any help would be appreciated.
The workflow you described of generating DTOs from a database and then moving the classes as well as making modifications is not something that will work with subsequent generations as you’ve found. The migration from database first to code first is suppose to be a one off change and you then manage all your models in a code first way from then on.
Eg, if you have added a column in your database externally that is not yet represented in your database model classes, you would add the associated property in the related class. To initialize tables using OrmLite you can use db.CreateTableIfNotExists which is what the InitSchema method does for the related auth tables. Note, this does not migrate changes to your database model classes vs your database schema, that would be external to your application.
There is a discussion on GitHub about a new feature for code first migrations if you want to have a read, this feature is available on MyGet but is not finalized, further docs etc will be coming soon. This might suit what you are looking for to manage migrations that already uses your model classes.
Hope that helps, let me know if I’ve misunderstood your current workflow.
I appreciate the quick response and link to Myth’z implementation which looks to be released soon. I’ll probably try and use that since it looks to be almost finalized except for some testing and maybe customer recommendations.
I have one recommendation of my own, just my 2 cents. You can take it for what it’s worth. You guys have a ton of documentation, but it’s actually too much, or maybe not too much, but scattered over time where some things are still how they are implemented today, but others not. I’ve scoured over the docs and YT videos so many times, but still don’t come out with a clear picture on things a lot of times. Leaving me to just keep going through code and more documentation. I know a lot of other ppl don’t want to have to decipher documentation though. Starting down the path of using ServiceStack is actually pretty daunting when you realize how huge it is and how many features you actually support. Also, maybe having a video on your home page that shows all the major features of SS. I know my first time looking at this, it took a couple hours at least realize this wasn’t just another .NET api, and another week or so to realize how many great features you have. Maybe if it was broadcast, that hey we do everything better than Microsoft, would be good
I know I would love to have some either video tutorials or written, that go from the very beginning of creating your services, all the way to deployment maybe. Just detailed tutorials of your features. Have each tutorial, or maybe multi video that shows each feature in depth and up-to-date. While the ones that are on YT now are either out-dated, or quickly go through the feature and don’t quite do them justice. Some of the newer docs are ok, but you still need to know the core of how SS works, etc as well which takes you back to the older ones, which then gets confusing. Like trying to implement the dart/flutter client into my app, there’s no client app templates anymore. Trying to implement the validation to map back to each respective input, along with using up-to-date state management has been a long process. I’m new to dart/flutter so that’s ok, but man would it be easier if there was a couple hour video that showed how to implement SS into a flutter app. Same thing with the web templates.
I do appreciate all the documentation you do have, and your search function is about the best I’ve seen on any documentation site! This isn’t me complaining, but more just getting some thoughts out that I’ve noticed while figuring this all out. I appreciate your company, and your product, your quick responses, and detailed answers. Have a wonderful night or morning, and I hope I didn’t cross any line by posting this.
This is actually really solid feedback and much appreciated! Awareness and messaging is definitely something we want to improve.
In an attempt to boil it down to some actionable items for us to look into, could you review the following to see if it gels with what you’ve said above?
YouTube series of videos focusing and starting on basics to deployment strategies (with associated written tutorials to support)
Curated docs for common stacks (web, flutter, blazor, other?)
Longer more in-depth videos/writing rather than shorter overviews
Any feedback about the Intro to ServiceStack video to improve the messaging would be appreciated.
This is something we are striving to get better at, so any input/feedback here, on the GitHub Discussions or Discord is always something that will heard and we will reflect on, so the more the better!
I agree we could do a better job at organizing docs around use-cases, the current state of docs came to be due to our feature-based releases where new docs are added with new features, then moving onto the next feature release without spending too much time refactoring docs to better tie it all together.
If you can list the videos & docs you find that’s out of date we can look at updating them.
The home page is designed to be organized this way which provides a summary and videos for ServiceStack’s major new features. A video covering all of them isn’t really feasible since there’s so many features that jumping from one to another will be confusing and its easy to lose interest when wanting to skip features they’re not interested in, overview of all features will also become quickly out of date with future releases. IMO it’s better to create feature-based videos as we’re doing so that devs can watch and learn features they’re interested in. If you have any suggestions on improving discoverability that would be good.
Can I ask if you’ve been reading the release notes to stay up to date with new features? I ask because we invest a lot of effort creating them to introducing them with background context which better explains the rationale for the feature, improvements over previous approaches, etc.
I kind of think our most recent videos does this, since our Litestream support is primarily based on deployment coniguration
SQLite & Litestream - Save 10x on hosting .NET Web Apps
Blazor WASM Litestream Apps
Likewise our newest Jamstack templates also goes from new Project to deployment:
Agreed, we’ve earmarked doing another iteration to improve our Flutter support in our next release after this one as we’ve done with Blazor. Flutter is different to other project templates since it’s so large and changes so frequently that it’s not feasible to create a project template which will quickly become stale and out-of-date, instead we intend to simplify integration efforts with mix templates to better integrate ServiceStack with new Flutter projects. Although I’ve rewatched our Flutter video and IMO it’s still valid for adding ServiceStack to Flutter projects:
FYI the first version of this is now feature complete, we’ll have docs out for this next release, hopefully we’ll also be able to release v6.3 as well.
Thanks for the detailed and explanative answer! As I’m going through the videos again and documentation I can jot down if I see something that’s out-dated or maybe could use a little more explaining, at least to me. And if it helps at all that would be great.
I do have a question about firebase authentication. Since every tutorial and YT video shows only firebase auth. Would it be a good idea to use firebase auth to grab a token from FB, and then pass that off to the JsonServiceClient, that way forgot password, email validation, and the rest of the mundane auth is complete and I can then use the SS client to do the rest by using that token from FB? Or is it feasible to wrap the firebase client in SS’s client, kind of like you did for the jamstack’s with the SWRV client?
And last, what would be the best implementation right now, i can get some ideas from, that would be closest to dart/flutter for mapping server field error’s back to their respective field? I’m sure it’s not as hard as I’m making it out to be, and tried to follow along with Vue’s SSG template, and port over to dart, but some of Vue’s syntax and just how the whole api.ts file works I’m not understanding. That’s my own inadequacy on not knowing Vue and even typescript good enough, along with only having a maybe intermediate lvl understanding of Flutter/dart now. Just a nudge on where to maybe look would be great.
Also, Rider’s SS plugin is not in their plugin’s anymore. Just an FYI.
Really looking forward to the new flutter integrations. Oh, and yes I’ve read and watched the release notes. You guy’s have come out with some great additions to the SS repertoire.
When you authenticate with ServiceStack you’re not using a 3rd Party token to call protected APIs, after authentication you’ll either end up with a Session Id for normal Cookies/Session Auth or if you have JWT enabled with a JWT Token (our Service Clients have support for both), both of these reference an Authenticated ServiceStack Session.
It’s just a matter of inspecting the populated ResponseStatus DTO and matching the populated Field Errors in Errors with the matching input control in Dart. Our World Validation docs shows example of doing this validation form binding in 10 different web development approaches we also do this in our Blazor UI controls, which is just matching the Validation Error field with the UI control with the same Id.
Thanks for reporting, @layoric can you look into this please.
Hmm, I tried using the world validation example a couple times because I thought that’s exactly what I need, but was getting errors when trying to go to the site. Oh, well, it’s working now! Thanks.
As for the auth with firebase, I know you don’t have anything to do with it, I was just wondering if it would be easier to implement firebase auth using their client first to get a JWT, and then pass that off to the JsonServiceClient. All flutter tutorials seem to use it and have had multiple ppl on reddit say that I should be using it since it’s built by google and battle tested, and then I can use whatever backend i want after being authenticated. Probably more work than it’s worth. I’ve used your JsonServiceClient in a # of web projects/tutorials and it works great. I’ve implemented the registration and authentication (signin/signup) but haven’t seen anything anywhere for forgot password, validating emails etc. Those will have to be implemented by me correct? I just don’t want to redo those if they are somewhere already implemented and i was just oblivious.
I try and only come on here to ask questions when I have a # of them built up. Sorry, last questions and then I’m done.
You would use their token if you want to call their APIs directly in which case you would use their client, if you want to use ServiceStack client to call ServiceStack APIs you would need to Authenticate with ServiceStack first which will be establish an Authenticated session that will let then be able to call protected ServiceStack APIs.
Yes, you would need to implement features like forgot password.
