Hi all,
Currently I have an existing Java REST API (around 400 - 500 APIs; developed using Spring Boot 2.X) in production. It’s being consumed by internal and external clients.
I am fairly new to learning Elixir (2nd attempt to learn Elixir again).
I am not sure rewriting this Java REST API is a good or bad choice.
Here’s why.
This Java REST API
- integrates to SOAP Web Services from vendors’ core systems (which I understand those core systems also using Java)
- provides an endpoint for those core systems to push data to my side to process
- comply to OpenAPI / Swagger
I plan to create an Elixir/Phoenix version as part of learning process, and maybe it can eventually replace that Java REST API if the new version can handle better than Java (not sure).
However, I am not sure whether Elixir/Phoenix will work well with SOAP Web Services when integrating with legacy core systems by 3rd party e.g. banks, insurances’ core systems.
Plus it also comply to OpenAPI/Swagger, if I change the API to Elixir/Phoenix, not sure will it impact my clients consumed it right now in production?
Or should I use Elixir/Phoenix for anything that don’t integrate to SOAP Web Services related?
Any help? Thanks.
The first question I would ask before re-writing anything would be: what is the goal? what is the current biggest problem? Is it scalability?
Elixir is based on Erlang so by default it is a good language for making a lot of small processes doing small things, parallelly.
Regarding SOAP, you have an Elixir client here: GitHub - elixir-soap/soap: SOAP client for Elixir programming language.
I assume you have a playground for development for banks and other organizations, try using it to see if you need to find a more advanced client or not, or maybe even write one yourself.
I worked with Java and Python and Elixir is much more pleasant to work with because of the build-in tooling and simplicity.
4 Likes
What problem are you looking to solve by rewriting in Elixir?
SOAP could be a problem. Indeed play with the requests / responses a bit from the Elixir side and see if it works fine. Not sure Erlang/Elixir cover SOAP very well but even if they do, many SOAP endpoints have quirks (I still remember working with these monstrosities some 15-ish years ago). Best way to find out is experiment.
1 Like
Thanks for replying. I am considering adapting Elixir, but wonder it can handle project like this.
Currently no issues with scaling. But no harm to compare, to see which one works best.
yes, usually there’s staging servers to test.
I also don’t prefer to consume SOAP. But since we need to integrate them more than they want to integrate my side, I have no choice too.
If SOAP isn’t elixir/erlang forte, then probably I won’t spend time rewriting it and focus on building other stuff (as part of my learning process).
Seems to have issues here, not sure how stable Issues · elixir-soap/soap · GitHub
I guess if i need to write it myself, I can refer to that project as a baseline.
I wouldn’t say SOAP is not Elixir’s forte, because a request is a small process and Elixir is good at that.
The problem SOAP is an old technology, while Elixir is a modern ecosystem.
Some time ago all code was compiled to ASSEMBLY, that doesn’t mean Elixir would be bad because it doesn’t compile to ASSEMBLY. Moreover, Elixir can be used on embedded devices with a project called Nerves.
This is just a similar example - think of the principles of the language, not the libraries you have at hand.
1 Like
There are also potential places where Elixir could help like with background processes. Soap is ancient but it’s also xml which could likely be covered as there are numerous libraries in addition to Erlang. Having a dedicated soap client or being able to pull in dependencies to speed up development would help but nothing is guaranteed on any platform really. It usually takes established players working with the tech to keep it fresh and soap is definitely bordering on ancient at this point. Erlang itself is ancient by comparison but there is far more mindshare keeping that current.
There is a great OpenAPI library for Elixir GitHub - open-api-spex/open_api_spex: Open API Specifications for Elixir Plug applications but I haven’t worked with it to know if there are edge cases it doesn’t cover well. If I were porting some of the Laravel APIs I’ve used, it can more than cover them because I was never perfect. I covered the main use cases and was human support for the few integrations we had.
Like others have said though, you probably won’t know until you roll up your sleeves and play. If this were me I would try to make a small prototype and see how I liked it. If there’s too much friction then bail. Porting other projects are always a great way to learn as it’s harder for me to evaluate novel projects without a base line.
2 Likes
Nah, it’s not that. At the end of the day SOAP is just XML over the wire and that’s well-covered in many languages, Erlang / Elixir included.
It’s more about the whole wiring and integration stuff e.g. Java had (back in the nightmare EJB days at least) plenty of libraries that could generate SOAP clients given WSDL files and it was decent. But I feel most language stacks abandoned such tooling so if you need something like that you might have to manually code a client.
Which isn’t hard, Tesla + one of the XML libraries and you’re set, but it still has to be said that it’s going to be manual and the code will not be generated (though admittedly I am not paying attention to that part of Elixir so maybe somebody figured something out there already, no idea).
As for Open API spec, that’s covered btw.
3 Likes
