Usually Node, but my favorite one is lua within nginx - because I could
What advantages do you find using Clojure over others?
@daniel since I know you, and since I know Lua compiles on lots of things, I’m going to dare to ask what platform you’re running that Lua app on? //hint, it might be cool to write the first add-on that’s running on a Lego Mindstorms NXT
@nwade Nothing that fancy - I was trying to prove to myself that you could secure a static atlassian connect add-on (i.e. no back end) by putting the jwt verification on the web server.
Clojure is on the JVM and can use existing Java libraries, so you know you’ll have support for any APIs and systems you’ll need to interact with. However as a functional language you gain a lot more safety and expressiveness. It also allows you to writing your front-end code in ClojureScript, so your front and backends can share common code.
If you’re interested in Connect Clojure development I wrote a series of blog posts on this.
and…? How’d you go?
Plain old JAVA :). Just answering for statistical reasons.
I’ve been coding Node.js samples since @rwhitbeck convinced me to give it a try. ACE certainly makes things easy, but even when you reach the limits, Node.js has plenty of libraries that make it easy to handle the essentials of web endpoints, persistence, JSON serialization, and JWT. Plus good tools for testing web applications. I’ve been enjoying Mocha/Chai and looking forward to trying pact-js.
We use Clojure and Clojurescript ^^
We wrote Automation for JIRA in Java (running on AWS Lambda in cloud though - no servers!) and React JS for standalone front-end.
In my (very biased ) opinion this is the best choice right now for doing Atlassian add-on development if you have to ship to both cloud and server.
Using Java for Cloud meant we could re-use about 90% of our back-end code in the server version (which runs as a standard p2 add-on - no connection to Cloud necessary). Developing the front-end as a self-contained standalone react app also meant we could just drop it into server and configure it with slightly different REST urls.
The only 2 things we had to take care of:
- Have all calls to JIRA behind a clean(ish) JIRA client api. In cloud it talks REST, in server it makes API calls
- Have a clean persistence layer that we implement in cloud to talk to AWS RDS and to AO in server. Though both implementations use QueryDSL actually and share a lot the code there too.
Because of all this, the Cloud -> Server conversion of Automation for JIRA took about 10 days (while I was on a road trip through Vietnam - so not even 100% focussed).
This is a very interesting use case for cloud and server development. I will be sharing your insights with my team. Thanks Andreas
Really helpful info, thanks Andreas.
By the way can you use NodeJs for Jira Server based or only for Jira cloud?
If you’re just using the REST APIs with Basic Auth or OAuth 1.0a you can use Node.js with Server. If you are building a plugin then you will need to build that in Java.
Ok. Thanks for your input.
I usually make it in php in back-end and nuxt in front-end.
I use LetsCloud as provider