Suppose you have a Schema that is used in a UI-App (e.g. Vue), a Node.js or Springboot Server and has to validate against Databases (e.g. SQL, mongoDB,...), and maybe some Micro-services running on whatever.
How and where do I manage a this JSON-Schema, so that if I have to change the schema for whatever Reason, that every architectural component can handle the new JSON-Schema(s).
Otherwise I need to update the Schema in up to 10 projects so none is incompatible.
Is it really as simple as having a git project full with just JSON-Schemas or do I need specific loaders for each language/environment?
Are there best practices that I am unaware of?
PS: I don't really think I need the automatically synchronized on runtime, so don't really think I need another Microservice to achieve that.
That being said, if a Microservice is the best way to go, then getting a Microservice it is.
If you keep them in a git project, how do you load them? Clone the project each time the app starts? It may work, but I would go with a more flexible approach that should take too much effort to be done:
Build a JSON schema repository accessible via a REST API
When the app starts, it makes a request to grab the schema (latest, or a specific version)
That way you get an uniform (and scalable) way of playing with the schemas. Even if you think about a hot-reload sometime in the future, you can leverage this approach to do that.
Here is an old project in this direction, you may give it a shot to see if it works (or for some inspiration, at least)
Related
Sorry if this is a generic question, but I have been given a task to develop a web application, and I'd like to use this opportunity to dive into and learn about Polymer (and maybe Vaadin components?).
I'd like to avoid reinventing the wheel. But I'm a newbie regarding Polymer. So, given the following task, is there any approach and component that will make the developing quicker/smarter?
Create an application which will allow at least two users to log in simultaneously and manage items in categories. The categories should be in a hierarchy of potentially infinite depth. The items only require a label.
The users should be able to perform standard CRUD, plus if one user makes a change, the other user(s) should see the change (if appropriate) without manually refreshing their web browser.
How should I approach this with Polymer?
Has anyone done anything similar?
I'm also open to Vaadin components if it helps.
Any help or guideline?
🙏
One way would be to start from an application template like polymer3-webpack-starter or pwa-starter-kit.
If you are looking to use Vaadin components like vaadin-grid, use polymer3-webpack-starter or one of the starters from the vaadin.com/start page.
If you do not need an example specifically with Vaadin components, then pwa-starter-kit would be a good starting point. Though it assumes familiarity with redux.
Pro: You can quickly get a running application that you can modify to your needs, and you do not have to set a project from scratch (build tool chain, module bundler, tests, configuration, etc - all of that is done already).
Con: Making modifications to the project setup won't be necessarily easy because at that point you will have to dive into the project setup that somebody has done for you.
12-Factor Apps suggest that you configure your application using environment variables. So far, so good. I can easily imagine that this is a good way to do it if you need to set a connection string, e.g.
But what if you have more complex configuration with lots and lots of values? I for sure do not want to have 50+ environment variables, do I?
How could I solve this, and still be compliant to the idea of 12-Factor Apps?
From a quick read of the configure link you provided, I agree with the author's claim that there is a widespread problem, but I am not convinced that their proposed solution is going to always be best. Like you, I don't relish the idea of having to define dozens of environment variables to configure an application. So here are some alternative ideas.
First, read Chapter 2 of the Config4* Getting Started Guide (disclaimer: I am the main author of that software). In particular, notice that its support for what I call adaptive configuration can go a long way towards addressing the concern that you ask about. Is Config4* the ultimate solution? Possibly not, but I think it is a good step in the right direction.
Second, the chances are that whatever application you are developing/maintaining has already settled on a particular configuration technology, such as XML files or Java property files, and it won't be feasible to migrate to using Config4*. This raises the question: is there anything you can do to avoid having a proliferation of, say, XML-based configuration files when you have multiple environments (such as dev, UAT, staging and production) in which the application will be deployed? I have outlined an approach for dealing with this issue in another StackOverflow article.
We've recently made the decision to move away from .NET and SQL on our backend and rather implement a nodejs solution with either MySQL or postgreSQL. My server guys are putting a standard restful API in place using sequelize as the orm middleware.
Does anyone have any experience in implementing breeze in such a scenario? I understand that I'll have to define the client metadata by hand, but once this is done, do I lose any of the functionality that breeze offers in a typical .NET implementation using the EFContextProvider and server generated metadata? Also, can I use a standard restful API call, or is additional configuration required on the server side?
I think this is an exciting approach.
Breeze does not (yet) offer node-ware for this scenario. You'll have to decide what features of the ContextProvider you like and port them to node. I don't think that has to be super difficult and we'd love to help where we can. This would be a terrific contribution to the community.
What you are looking for in "a standard restful API" will determine many of your design decisions. Do you want to support OData style queries so that client code can compose queries? Or will you take a different approach?
Do you intend to have separate PUT, POST, MERGE, and DELETE calls for each resource? Or will you have some notion of "change-sets" for combining multiple save operations in a single transaction? Something in between?
Breeze favors a change-set approach out of the box. OTOH, if you want to go "straight" REST, there are RESTy Breeze dataservice adapters that suit that style with more on the way.
You can could learn a lot about the mechanics of query and change-set saves in Node by looking at how we handled them in the "breeze-mongodb" npm module referenced in the Zza sample for Node + Mongo.
Take a look at our MongoDB example. This is the breeze client talking to a Node/MongoDB backend. It's not exactly what you are looking for but it does should how one can build a Node backend to talk to Breeze. Also feel free to contact breeze#ideablade.com about consulting in the event that you need help with or want us to implement such a backend.
As a note there are now several samples on Github using node server / breeze / [mysql|postgresql|etc...]
Docs explaining -
http://breeze.github.io/doc-node-sequelize/
Related repositories -
https://github.com/Breeze/breeze.server.node
In my Repositories, I am making assignments to my domain objects from the Linq Entity queries. I then have a service layer to act on these object returned from repositories.
Should my Domain objects be in the repository like this? Or should my repositories be restricted to the Entities and Data Access, and instead have my service layer make assignments to the domain objects?
Doing all assignments in Repository seems easier, but now the distinction between my database and domain objects is not apparent. What is proper practice here? tia
IMO if the app is relativly simple and you cant imagine ripping out the Data access go ahead and make the asignments in the Repository. But if you think the app will get more complicated in the future or that you may want to change the data access keep this functionality out of the repositories.
I have done apps with assignement in the repositories and other in the service layer and yet another one i had a seperate conversion layer (it was not a one on one conversion and the objects were complex).
One thing to remember about best practices, There there to help, if it makes thing more dificult then dont use it.
I used to not like it. But now usually never look back. Basically the thing is that if you need to change to an external datasource that is structured different, you can set up a new mapping along with the implementation of the repository code and be done with it.
It is about data mapping. Check this link: http://www.martinfowler.com/eaaCatalog/repository.html
Also check this related question: IRepository confusion on objects returned. I have used a similar mapper, but have made it operated at the IQueryable level, which have made able to do some pretty interesting stuff while working with the Domain Object after the mapping.
We have a website that uses #include file command to roll info into some web pages. The authors can access the text files to update things like the occasional class or contact information for the department.
My question is this, I don't see anyone using this method and wonder if it is a good idea to keep using it. If not, what method should I transition to instead?
I don't think there is anything wrong with it, and I've done some similar things with PHP. If the people that make the changes are comfortable with how they do it and they can do what they need to, I think you should stick with it. There could be some retraining involved and/or a fair amount of work involved for changing the system.
If you are using ASP.NET then you could bundle that code into a nice little UserControl that will display all of the important information.
Other platforms should allow you to bundle the logic into a class object, and display it using that.
It really depends on the platform that you are using to deploy the application in. The include file could be your best solution if you are deploying in a more limited platform.