Choices made on the road to 0.1

You can drive yourself mad wondering if you made the right choice with regards to technology. This really is a difficult question to answer as you have to pick components that have longevity and that are in widespread use. The truth is that you just have to pick something and go with it. I think about popularity of libraries, how active development is etc before I make a choice but it’s not easy to just decide. Any component I use now will follow the project and code for a long time going forward.

This week I was wrestling with AngularJS and ReactJS. Basically it boils down to whether or not  I go with Google or Facebook. I picked up some cheap courses on Angular and that kinda made that decision. I’m not really that bothered by the GUI side of things at the moment, but I do need an administrative GUI and would like to have an idea how a proof-of-concept GUI would look. Given that this is a REST service, it will be possible to swap Angular out with whatever you want anyway. It is a very time consuming process trying to figure these things out.

The last month has been spent wondering how I should structure the project. If I get the foundation wrong, it will have a negative effect on the project.  Baeldung has an interesting project structure with a clean definition of modules and what should be within the modules. This quickly became the basis of my project structure. I kept coming across jhipster and after days of hassle (installing npm, bower, yo) getting it installed I managed to get an interesting project setup. What I learnt from the jhipster sample app was support for swagger, metrics, spring-security, angulaJS and yaml project configuration. I was initially unable to get the jhipster app to run so I have spent the time studying the code and structure and gradually copied elements over to my project. This has resulted in the nikita code base supporting swagger, the introduction of metrics support, and spring security  user configuration, all copied from  the jhipster sample application.

This approach has really saved me a lot of time and answered many questions about spring and spring-based applications. I have learnt so much from this approach. A plus with such an approach where I try to study best practices is that I hopefully will end up with a good project structure and robust code. A negative is that I’m learning as I go along. Ideally I’d sit down and figure everything out in advance but I think that’s the primary reason why it has been difficult to move this project forward over the last couple of years, I never had my own concrete project structure to work with and was unsure how to proceed.

I also switched coding from Eclipse to Eclipse STS to IntelliJ Idea.  I never seemed to be able to get things working nicely in Eclipse and STS. I always ended up with issues like it wasn’t possible to find   source code when debugging  or download sources and documentation didn’t work properly. I spent a lot of time on stackexchange but it really felt like a waste of time and I didn’t have an environment I felt comfortable and productive in. Idea has been a dream to work with. It just does things intuitively and the integration with git has allowed me to push code and changes quickly to githhub. I have never been so impressed with an IDE as I have been with Idea. It just seems to make sense.

I was also able to confirm that OData support is still in the draft version of Noark 5 v4 and will more than likely be in the final version. This complicates development of the REST-service significantly but I think I will solve this in the  codebase by supporting two apis, one with OData and one without. The reason for this is that OData support requires me to handle all incoming HTTP requests manually. To be honest I am unsure about the usefulness of  OData in a running installation, but if the standard specifies it then we simply will have to implement it. There is very little REST OData support in the java ecosystem, but there is something available that we can use.

Currently the code is very much a pre alpha version of v0.1. It  is mainly a working  project structure with the above mentioned libraries and  with the domain model copied in and the fonds object is accessible via a REST controller. Don’t expect the code to work until it hits the v0.1 mark as I am updating it continuously. You can check out the code from the github repository.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *