Creating PDF's I probably would, since there are good Java resources for that. Anything that's really heavy on database operations I'd probably use JEE and an ORM. The idea that some projects aren't worth the effort to make Java webapps and some are. Developing a JEE webapp is a lot of work, and that's basically what we've been discussing here. I think you've confused Tomcat development with JEE webapp development. After that, you're good for almost anything. Spring ORM does need 2 extra libraries in Tomcat, last time I checked.
#NODEJS REST API DRIVER#
Although a complex app might require adding a JDBC driver jar to Tomcat and a deployment descriptor file (context.xml).
#NODEJS REST API INSTALL#
I can live with the relative fragility of a JavaScript app here since even when it does occasionally go pong, nothing worrisome happens.Īll that's required to install Tomcat is to download, unzip, and run the startup script.Īll that's required to deploy most Tomcat webapps is to drop them into the TOMCAT_HOME/webapps directory. And it wasn't worth spending several days making a Java webapp out of it. It doesn't need speed, it's not accessible outside the LAN - and doesn't contain anything critical anyway. Also, the same micro-server contacts my home automation server to get the current outside temperature and the message-of-the-day.Īll of this is a fairly small NodeJS aggregator.
![nodejs rest api nodejs rest api](https://freecoursesite.com/wp-content/uploads/2018/11/1879018_95b6.jpg)
That task reads weather predictions and squashes them down to a 1-word verdict for the workday, which is then saved and repeated as needed. Well, actually, it's national, but for my own locality. That server also runs a cron task at 4am each morning to the local National Weather Service node. Once a minute, it sends out a ReST request to an in-house server to get the time of day in minutes (e-ink is best when the display doesn't change too often). It has an e-ink display and builtin WiFi node.
![nodejs rest api nodejs rest api](https://miro.medium.com/max/1824/1*6BbOjcBAEQHUqgs9EMXX8g.png)
![nodejs rest api nodejs rest api](https://cdn-images-1.medium.com/max/1600/1*YofxX8XmRkh_uB4XMyq34g.png)
I have a neat little device I built hanging on my kitchen wall near the door. One of the most commonly-used micro-services on my own LAN is a NodeJS program. At the cost, of course, of having to code more carefully and think further ahead. Any loosely-typed language (such as javascript) gets automatic dirty-points because they've forced the choice between careful vetting of data usage onto the developer, who is then free not to do so, especially when the boss is breathing down "Git 'er Dun!" Java, being strongly-typed, does that checking automatically. But I still prefer the phrase, since it contains an explicit reminder that everything has its price.Īgain, speaking for myself, "quick-and-dirty" implies that minimizing the time-to-delivery is the priority, not robustness or security. For me, quick- and-dirty is a bit redundant, since computers pretty much conspire to ensure that anything that can be done in a hurry is littered with caltrops.