What is the correct approach to structure a ServiceStack project?
As of now I do it in the following way:
Under ServiceModel,
I have all the models (entities), and have defined the different routes ("/product") and so on.
Then should all the CRUD operations should be under ServiceInterface?
The purpose of the different projects are covered in the Create your first WebService docs (from Physical Project Structure docs).
Essentially all DTOs accepted and returned by your Services should be in your dep-free *.ServiceModel project. All your Service implementation and supporting classes should be in your *.ServiceInterface project. If your project gets too big you can move your supporting classes into different projects. You can also split your Service implementations across multiple assemblies although I'd only do that after moving supporting functionality into different projects first.
As you're new to ServiceStack I'd also recommend skimming through other docs for background reading on developing Services and structuring your solution:
Design RESTful Services
Design Message-based APIs
Complexity, Services and Role of DTOs
Related
I've inherited an aem project which has core, ui.apps, it.tests, and ui.frontend modules. The frontend is nodejs. The core module has java codes, but I don't understand what's using it. Search results for "what core module is used for" returns "Core module contains java codes".
Typically the core module will contain Java-based services - primarily OSGi components with implementation/business logic required by the project. This could be just about anything, from custom servlets intended to directly handle user requests, to scheduled tasks, model POJOs, extensions/plugins for OOTB or third-party frameworks, and many others.
Is this module required? That's hard to answer, since it depends on the project, but generally speaking most non-trivial AEM projects will have some amount of Java implementation.
Most projects nowadays will be using a framework known as HTL (a.k.a. Sightly) which is an HTML-esque template language that can invoke Java/server-side code via special HTML attributes. If you see any Java classes that extend WCMUsePojo, these will be providing domain logic for some front-end component(s).
If you see classes annotated with #Component/#Service (there are other annotations but these two are the most common) then those will be providing some kind of back-end functionality. You'd need to look at them case-by-case as they could be doing just about anything.
It really is a broad topic, and you'd be wise to read up on AEM development in general if you've inherited a project. Hopefully you also inherited a copy of AEM you can spin-up locally to familiarise yourself with the platform and your project.
Is it be possible to customize/extend JHipster for an organization ?
By that, I mean having a local version that creates some projects with features that are specific to an organization ? For example, using a custom authentication scheme (that still relies on Spring security), using custom styles (colors, fonts), adding certain Maven dependencies and so on.
If this is possible, can it be done while retaining the possibility to update JHipster in such a way that an update of JHipster would not overwrite these extensions ?
Thanks.
Here's the approach in general:
First, we created a blank project with all standard JHipster
stack. DBMS used is Postgres. We outlined the basic data structure
with jhipster entity generation tool, creating the most important
relations etc. We also defined the basic user roles and permissions
within standard JHipster options. At this phase we didn't pay very
much attention to the details such as complex unique constraints,
business restrictions, user management, JPA errors handling and
presentation etc. Just created a sort of backbone to start with.
CRUD pages are all standart.
We introduced some domain-specific business logic. Basic frontend customization was performed: branding,
styles, some custom views (still used bootstrap classes extensively) etc. Jhipster-generated frame was kept in place but extended. We changed authorization logic a little bit on both backend
and frontend, it's token-based with certain token validation
rules. User-friendly error handling was introduced, allowing user to
understand what business restrictions show up in various conditions. We started to write more complex unit tests to meet the business logic implemented recently. Entities are mostly (~80%) crafted manually at this stage, because we got used to the data structure offered by JHipster, and we had too much customization in CRUD REST controllers, pages and tests covering all that. Liquibase changelogs were generated with liquibase:diff and edited manually. We don't add such entities to .jhipster folder.
Because of demands for interface design growing high and strict, it was decided to introduce separate frontend layer for end-user interaction. It partially shares REST interfaces with jhipster-generated frontend, but is absolutely independent in terms of project structure. We decided to use Angular for new frontend layer as well. In fact, it is a subfolder with separate index.html, bower.json, Gruntfile.js etc. At the same time we continued to improve business logic, refine db structure, increase code coverage, introduce new user roles etc.
...
So we have slightly customized "old" JHipster frontend for administration and data mangement purposes. And an independent "new" frontend with custom design to deal with end users. Please note: it IS possible to keep an original interface, customize it to some limit and preserve the possibility to generate entities, and it worked well in our project as far as it was justified.
Some notes:
Component versions in pom.xml were constantly updated by hand;
Maven dependencies were manually added to pom.xml;
JS dependencies were manually added to index.html/bower.json/app.js;
If you have complex frontend scripting, dealing with JS uglification for production profile may be tricky;
Another difficult thing is to keep liquibase scripts working for both DBMS used by spring-boot and H2 which is used for tests;
You'll probably face some problems with configuration tuning depending on domain logic specific for your project.
I hope it helps.
Another approach that has been introduced in release 2.26.0 (mid december 2015) is to build your own modules, see documentation.
Later on in release 5.0.0 (mid 2018), JHipster has introduced a more powerful tool: blueprints, although it requires more effort than creating a module. With a blueprint, you can even replace the language/framework of the generated project, it has been successfully used for Kotlin, NodeJS and VueJS.
Given the most awesome release of the Visual Studio Extension for ServiceStack, I wanted to make sure that after creating my service with ServiceStack, that when I create a client to consume said services that I'm doing it correctly. By that I mean in a loosely coupled, high performance way.
Let's say that we examine the EmailContacts project so we're all on the same page. The Email Contacts project has a reference to both the EmailContacts.ServiceInterface and EmailContacts.ServiceModel, this is understandable as this IS the service. Now I want to consume this service from another .NET project, doesn't matter what type, console or web.
So my question is this "In the consumer application, will I add a reference to EmailContacts.ServiceInterface and EmailContacts.ServiceModel and use the ServiceStack C# client library?", I don't see where I have a choice not too.
Thank you,
Stephen
Keep Service Models in their own Assembly
The benefit of having a well-defined Service Contract where your DTO's are maintained in their own separate impl-free project is that clients will only ever need to reference your Services DTO's to use with one of ServiceStack's C#'s Generic Service Client to call any Service.
Add ServiceStack Reference
Clients are also able to avoid referencing any of your Server dlls if they use ServiceStack's Add ServiceStack Reference feature which provides another way for clients to access your Web Services DTO's.
Clients shouldn't reference any Server implementation projects
It's a code-smell if you find clients needing any reference other than your Service Model and ServiceStack's client libraries, which is an indication that your Service Models aren't in their own dependency and impl-free .dll, which shouldn't depend on anything other than ServiceStack.Interfaces.dll.
I got the week off from work to learn servicestack and I am in awe of its simplicity, power, and speed.
I am a pluralsight subscriber and I am going through the Jon Somnez course which is great and as far as I can tell is using the new service stack api.
However, the examples in the pluralsight course are extremely simple and as such I am looking for a working example THAT USES the new API. I see that the wiki is up to date and that is very helpful...but I was hoping to find a working implementation that uses the new API and it seems that all of the examples I have downloaded or browsed are using the old API.
IS there a new working example/implementation (vs solution and projects.) that uses the new API yet?
If I can sneak in another question. Is there a recommendation (hopefully in the example project you can point me to) that explains a best practice for structuring your servicestack API project. (DTOs in a folder, services in a folder, response objects in a folder ??)
Thanks.
Update: ServiceStack Live Demo's and Examples are now being published on LiveDemos GitHub Project.
Most of the examples in ServiceStack.Examples has switched over to use the New API and are mostly available to demo on the servicestack.net homepage.
ServiceStack.UseCases contain a number of small single-purposed applications that are focused on how to enable specific features for different use-cases.
The SocialBootstrap API deployed at bootstrapapi.apphb.com is an example of an MVC and ServiceStack website together making with all the available authentication options together.
The Razor Rockstars is an example of a stand-alone ServiceStack application that demonstrates its website and HTML capabilities showing how you can add razor and markdown views to existing services to create a website that enhances existing services. There are 3 versions of Razor Rockstars available:
An ASP.NET Host
A Stand-alone Self-hosted using HttpListener
A Windows Service
Another website that's similar in spirit to Razor Rockstars is the Nortwind Database editor which demonstrates how you can enable a full-featured server-side HTML website to enhance your existing services. It includes a full-writeup of how he developed it and its capabilities on the accompanying blog post.
I was wondering whether or not BreezeJS is compatible when using other technologies other than Web API and/or Entity Framework? As I'm currently in development of a SPA using Service Stack to retrieve data and ORMLite?
So I am curious how BreezeJS handle's this as I know it uses it's own API Controller usually with an extension of the DbContext class which Entity Framework uses. Thanks.
There is currently a sample called NoDb in the samples zip available on the breeze website. This sample does not use EF, but it does use WebApi. So I'd start by looking there. ( additional documentation on this sample should be added within a day or two as well).
In terms of using ServiceStack instead of WebApi, breeze supports the concept of a "dataServiceAdapter" and currently ships with two, an OData adapter and a WebApi adapter. It is certainly possible to write a ServiceStack adapter that breeze could use but this is not trivial. Please add this as a feature request ( and vote for it) on the breeze User Voice. We take these requests seriously.