Will FP be a good alternative to Go when writing microservices in backend? lazarus / 38-Networking and Web Programming ---------------------------------------------------------------------- apterpont · 2022-05-01 07:40 After reading this article/rant: https://www.reddit.com/r/programming/ comments/uenpw2/lies_we_tell_ourselves_to_keep_using_golang/ I started looking for something that would treat JSON missing fields better by default. How is FP in this regard? E.g. if some of the JSON field is missing will it be treated as 0 or null or something else? Is FP a suitable alternative to Go for writing microservices for my web projects or I should stay with Go despite the problematic JSON treatment? Or try to use something completely different than FP or Go? Have any of you done some microservices programming in FP? How it went? What pros and cons can you mention? What was good, and what was not so good? Thank you in advance. ---------------------------------------------------------------------- marcov · 2022-05-01 12:02 FPC json classes currently don't work with automated marshalling. I don't know GOlang that well, so I can't comment on the other. ---------------------------------------------------------------------- PierceNg · 2022-05-02 02:15 I've written a low-traffic microservice in Pascal using fcl-web and SQLite: It accepts HTTP POSTs, stores data in the SQLite database, and periodically processes said data. The service runs in a Docker container. No idea about auto-marshaling of JSON since the service doesn't face that. I use fptest for unit testing and fpmake for building both the service executable and the unit test driver program. Building headlessly using fpmake (or your own shell script) allows plugging into automated CI system. For low volume microservices and monolithic web apps, available framework/libraries in Free Pascal work fine. This is not to say that Pascal is unsuitable for medium to high volume services, just that I have no experience using Pascal in these. But considering that people do run high-traffic sites/services implemented in Python and Ruby, probably Pascal won't do worse than those. Main con in using Pascal is the comparatively much smaller ecosystem, so although Free Pascal comes mostly batteries included (here I mean also the stuff available on Github etc), your app code may have to deal with battery wiring and implement some batteries itself. I've not written web stuff in Go, no comment. ---------------------------------------------------------------------- SymbolicFrank · 2022-05-02 07:05 There are many ways to write microservices. If you want something that translates code into JSON and URL's automatically (and vice versa), Free Pascal isn't going to do that. On the other hand, Free Pascal is fully object-oriented, so if you want to be able to understand what happens and have more than just one or two microservices that only pass values to and from a database, it's far superior. It does have multiple JSON classes and there's even a few that treat JSON like a dataset. Both allow you to run your code as a single executable that has the webserver build in, on multiple platforms. ---------------------------------------------------------------------- PascalDragon · 2022-05-02 13:11 Quote from: marcov on May 01, 2022, 02:02:08 pmFPC json classes currently don't work with automated marshalling. Something like fpJSONRTTI doesn't factor into that answer? ---------------------------------------------------------------------- SymbolicFrank · 2022-05-03 07:00 Quote from: PascalDragon on May 02, 2022, 03:11:40 pmQuote from: marcov on May 01, 2022, 02:02:08 pmFPC json classes currently don't work with automated marshalling. Something like fpJSONRTTI doesn't factor into that answer? Interesting, I didn't know of that one, either. A bit too static for a WEB API, but nice to know it exists. ---------------------------------------------------------------------- PascalDragon · 2022-05-03 07:22 Quote from: SymbolicFrank on May 03, 2022, 09:00:46 amQuote from: PascalDragon on May 02, 2022, 03:11:40 pmQuote from: marcov on May 01, 2022, 02:02:08 pmFPC json classes currently don't work with automated marshalling. Something like fpJSONRTTI doesn't factor into that answer? Interesting, I didn't know of that one, either. A bit too static for a WEB API, but nice to know it exists. Depends on the use case. If you have simple data objects then fpJSONRTTI might be right (after all it's only serialization and deserialization, it's up to you how you make use of it). For more dynamic “actions” you might want to take a look at JSON RPC especially the new one utilizing RTTI. ---------------------------------------------------------------------- marcov · 2022-05-03 08:34 Quote from: PascalDragon on May 02, 2022, 03:11:40 pmQuote from: marcov on May 01, 2022, 02:02:08 pmFPC json classes currently don't work with automated marshalling. Something like fpJSONRTTI doesn't factor into that answer? I was thinking more about extended RTTI. You can also hack it old- skool of course.  The example in the wiki for fpjsonrtti doesn't inspire much confidence in me. It seems the constructor is of importance for collections, but there is no virtual constructor. So how would .JSONToObject() work when the TNamed object also had a collection? ---------------------------------------------------------------------- PascalDragon · 2022-05-03 11:31 Quote from: marcov on May 03, 2022, 10:34:44 am The example in the wiki for fpjsonrtti doesn't inspire much confidence in me. It seems the constructor is of importance for collections, but there is no virtual constructor. So how would .JSONToObject() work when the TNamed object also had a collection? I don't know which example you mean, but maybe you should point MvC in its direction then so that he can make sure that it's sane... ---------------------------------------------------------------------- SymbolicFrank · 2022-05-03 11:39 Quote from: PascalDragon on May 03, 2022, 09:22:06 amDepends on the use case. If you have simple data objects then fpJSONRTTI might be right (after all it's only serialization and deserialization, it's up to you how you make use of it). For more dynamic “actions” you might want to take a look at JSON RPC especially the new one utilizing RTTI. Use case 1: you build a REST API. Implementing all the functions on the outside and handling the traffic and JSON is a lot of work, so it is nice if you can just build a class that does the actual work and generate the whole interface from that. Including the documentation, so others can communicate with your server. This is what most developers do. Use case 2: you build both the client and the server. Unless there's proxies in between, don't bother with things like JSON. Make up your own protocol. That also allows more data types. Or use an existing library, that offers an easy interface at both ends. Use case 3: you have to implement the client side for multiple WEB APIs (most of them a REST variant), with hundreds of functions. If you have a code generator for each, you can use that, but be prepared to keep regenerating, fixing and recompiling that code. Or do it on the fly, where the APIs are generated in memory. As long as there's a function and field with the expected name, it keeps working. Works best when you treat it like a database. And don't raise exceptions. You do have to replace the URLs occasionally and connect the new functionality supplied, when requested. 1 and 2 have multiple implementations, but I haven't found a good solution for 3, so I'm making that myself. It doesn't help, that it is so easy to change the interface if it is generated form code. Also, REST services are far less standardized than things like SOAP. Simply because a lot of things don't easily fit inside a JSON message. And there's a multitude of API descriptor file formats.