this is what I have so far achieved with Jhipster:
1 - Create my entities and relationships
2 - Generated my application
3 - Built the application and confirmed that I am happy with the existing entity-relationships.
I am now ready to start writing business logic.
My concern is that I haven't found any information on the JHipster website to guide me. I was hoping to find some guidance with regard to customisation and extension of the generated code.
I am wondering if there are any best practices ?
My next tasks are :
customize the GUI - removing some elements that the user will not need to input but will be stored in the database.
write java code to populate above elements in controllers
write business logic that can be called by controllers
I am wondering what will happen when i need to alter the existing set of entities?
I am wondering what will happen when i need to add new entities?
I will need to regenerate the code.
So far from what I have read there is a lot of manual work involved to resolve the above once customisation/development has started.
Is this true ?
Does anyone have any suggestions on how best to proceed and use Jhipster in the most production manner - with as little manual "merging" as possible ?
Thanks a million,
Fergal.
Related
I come from express.js background and pretty new to loopback framework, especially loopback4 which i am using for my current project. I have gone through the loopback4 documentation few times and got some good progress in setting up the project. As the project is running as expected, I am not much convinced with project structure, Please help me to solve below problem,
As per docs, database operations should be in repositories and routes should be in controllers. Now suppose, My API consist lots of business logic along with database operations say thousand of lines. Which makes controllers routes difficult to maintain. More difficulty would arise, if some API demands version upgrade.
Is there any way to organise the code in controllers in more
scalable and reusable manner? What if i add one more service layer
between controllers and repositories and put business logic there?
how to implement it in the correct way? Is there any official way to
do that which is suggested by loopback community only?
Thanks in advance!!
Is there any way to organise the code in controllers in more scalable and reusable manner?
Yes, services can be used to abstract complex logic into its own separate class(es). Once defined, the service can be injected into the dependent controller(s) which can then call the respective service functions.
How the service is designed is dependent on the user requirements as LoopBack 4 does not necessarily enforce a strict design requirement.
I notice that JHipster microservices have their own Auditing viz. PersistentAuditEvent it seems easier to use than say AuditEventRepository which only has add and some limited find methods.
I want to save an Event of a task being run with a role of SYSTEM and identify it by something like type:executedLongQuery
Then in future I want to check the last run of this query and decide whether we need to run in again for report generation then log an event again if it is run. It seems to me PersistentAuditEvent offered by JHipster is the best way to go.
I don't see a PersistentAuditEventRepository or any suitable implementation within the microservice so if I can get a documentation with example that would be very helpful. Even a clue in the right direction could help me start.
I found the repository interface and a custom implementation in JHipster Gateway which is not present in microservice. It was easy to simply copy it over to microservice and use the repository. Ofcourse here I am using a database in the microservice, an empty one, which still adds the migrations as well as Audit tables.
I'm doing a system as my final year project, in university. My team members have different views on the development approach to use.
Does code first have more advantages than database first?
We'll be using mvc5 and will be deploying on azure.
Any feedback would be appreciated.
[Code-first vs Model/Database-first
This is for an older version but still valid.
We use code first but ultimately its an approach and you will find as many people for one as another. At University I was taught to design the database first as that was the methodology used to help structure it correctly and make you think through it. Now we use Code First but I approach things very differently to the Uni years as I have so much more experience. Its still EF at the Core so go with what complements your skills and maybe how you have been/are bring taught.
I would argue for database first. Why? Well, if somebody is designing the data model they are more likely to encode that model in the database.
If you opted for code first you will be modeling the domain (optimally) and then creating the database based upon conventions in the framework.
Once you have created the database you are back in first camp. Once it exists you will use code to access the data and not recreate your data model in the database.
I like a lot Cucumber and I find a very useful tool to solve problems seeing them with an outside-in approach so I would like to use it as part of chef projects too. I have successfully integrated it into the project I'm working on but at the time of writing business goal of features I have some doubts.
Who is the end user here?
Regarding on this the feature will be more service oriented or not, ie:
If the feature is more architecture faced the I could write a MongoDB feature which describes that I need up and running a MongoDB service and that the applications is linked to it.
In the other hand I should just write application features, forgetting about the infrastructure behind and then assume that if the cucumber tests run well for the application then it means that the infrastructure is fine too. (I dont like this approach)
Which of the both approaches are better? I like the most the first one but I'm just a noob on these lands. Please give me your considerations.
Ok, here's the thing.
I have a good JS background, had my share of JS in the past, and have lots of cool bare-bones tools I take with me from project to project that act like a library.
I'm trying to formulate work with CouchDB.
Now, after getting used to luxury of cool tools that you wrote and simplify the language for you - I find it a little frustrating to write many things in bare-bones manner.
I'm looking for a way I can load to the database context a limited, highly efficient and generic set of tools that focus on the pure language and makes the work with the language much more groovy (and gosh, no, im not talking about jquery or any of the even more busty libraries out there).
If on top of that, there could be found a way where I can add to the execution context of the couchDB JS engine some of my own logic tools (BL model functions) - it would present a great and admirable power and make couchDB the new home for a JavaScript-er like me.
Maybe I'm aiming too low.
I'd be satisfied with a way I can allocate a set of extensions even for a specific database, and I don't mind do it for every database in separate. Or worse - to add it to every design document, so I can teach for example several views in the same design-doc what a Person is, what a Worker is, and use their methods to retrieve data from them according to logic in a reusably coded manner.
Can anybody point me the the way?
Whatever way you can point me - I'll be very verrry grateful.
If there are ways for all of these - then great.
Trust me to know the difference of what logic belongs to what layer...
You open my possibilities - I promise to use them :D
CouchDB now supports code sharing as CommonJS modules.
http://docs.couchbase.org/couchdb-release-1.1/index.html#couchdb-release-1.1-commonjs
http://caolanmcmahon.com/posts/commonjs_modules_in_couchdb
In this way, you can share your javascript modules between views, lists, and shows in the same design doc. (Server-side)
Also, you can load these modules on the browser side with this library:
https://github.com/couchapp/couchapp/blob/master/couchapp/templates/vendor/couchapp/_attachments/jquery.couch.app.js
You also might want to look at Kanso:
http://kansojs.org/
It does a really good job of making your javascript work seemless between the server and client.
You can find some helpful tools here : https://github.com/vivekpathak/casters
The running examples and test cases may particularly help you.