This article is not about React.js (or Vue.js, or other rendering libraries). I read random professional articles online. There was another Node guy trying to claim he invented sliced bread, or rather “exciting new ThinBread (tm), so much easier than all those bread bricks”.
This describes an architecture (not pattern) that they called reactive 1 2 3, the article referenced the first link. At least one artist is involved reactive development, as they have a manifesto 4, to summarise to the point of triteness a reactive system is one that is Responsive, Resilient, Elastic, and Message Driven. The “enterprise” Java culture seems to be buying the idea of Reactive architectures 5 6 7 8. The last link is SoundClouds architecture. It seems to be a common Haskell structure 9 10 11, for a while 12, that links work from 2011.
The first Wiki states that Reactive is fine with OO, for example OO languages with reactive architecture libraries red lang, C++ and java. Many people use it with functional programming, and made a new acronym ~ FRP 13.
As ever I reference a language that people are more likely to pay me for 14, which states there a variety of options for reactive systems. Many of these options need PHP extensions to run efficiently. There is an extension specifically for eventing 15 16. Threading in PHP isn't really mature, there is an optional extension that links pthread to the main interpreter. Alternatively PHP has a stable extension called cntl, which has POSIX C API like fork(), signal(); I have little server-side experience on ms-windows, but I suspect that these do not work on there. A quick google yielded a list of projects for the frameworks 17 18 19. This last project is deprecated, although reading the project index is encouraged 20.
Java example, outlining a list of reactive Java frameworks, supplies some code samples 21. Here is a “study project” in Java; the analysis is worth reading 22. Another discussion on Java 23.
For Node, the underlying language has alot of work on async, events and callbacks. I note that MSFT are publishing Reactive Node libraries 24. Finding out “actual reactive Node frameworks” is hard, as Node doesn't really separate performance things clearly, and is always asynchronous.
I personally react badly to hype. If you can build a system with all these (reactive) characteristics, you have high performance engineering, regardless of buzzword compliance. Similarly if you can fit a Ferrari engine into a cheap fiat, it will drive fast; regardless of the logos. I think that if you abstract the synchroneous I/O to a thing like Kafka (so avoid the core features of PHP), you could also make a fast platform. My sole reason for doing this in PHP, is when someone asks me to solve a problem with a really poor implementation; I would have a smarter solution to hand.
How can I make code responsive?
The following are things that I have done in the last year to make code faster:
- Be careful with DB access, use an extra caching if needed.
- Be careful with 3rd party API access, use an extra caching if needed.
- Avoid long processes, i.e. need to do “a,b,c,d,e,f” either make that more than one API, or design for an asynchroneous response
- Only do work now that is needed, now. For example don't parse YML config files on each execution, translate them into a language array, this loads faster. ¥
- Collapse source code into disk friendly blobs, rather than small classes. ¥
- Avoid nested loops, it is possible to update multiple counters per iteration, if each variable has the same number of states
- only use the RAM that you need, as the interpreter copying large blobs of memory around, and needing a reshuffle on all the variables slows execution down
- Know what expensive language native functions are, and limit their use. Only to be done after business requirements are meant, but for example use while loops over foreach.
¥: ie these items are done with a compiler.
How can I make code elastic?
Due to the type of work I am hired to make, I can demonstrate less experience in Elastic structures. MongoDB and Apache are examples of fairly elastic tools, they scale numbers of worker processes/ threads to match the workload. Elastic code requires some sort of middleware, acting as a load balancer and task manager. As creating a new process is quite expensive under Linux, there are many stupid/easy solutions that don't work.
- Define your processing structures with a Worker/Master pattern. The workers population can be elastically expanded to meet requirements.
- Where practical, lean towards statelessness, its scales much more easily.
- Do some resource analysis, find and remove the contention points.
How can I make code more resilient?
This is a long list of platform changes, and constraints. There are many devops people who spend their entire working lives on this metric. A search engine will supply many products that will perform a particular facet.
- Catch all the Exceptions, and do the most sensible action when the Exception happens.
- After creating a dependency tree, work out what is possible if any of the subsystems has failed. For example, at a devops lecture I went to; the speaker had a abstraction on front of his database, which received and queued SQL queries.
- As an extension of the dependency analysis, less coupled code, where practical, is more stable as Exception conditions can't affect so many features. Also, validate the messages passed between subsystems, to further isolate failures.
- Have a monitoring system which can take action when it observes failure. Being in a different process mean that the monitor is less likely to be affected by an issue that is impeding the main system.
- For external subsystems like databases, implement retry code for connecting. If there is an issue, the system will be more resilient if it comes back automatically.
- Like MongoDB, structure code so Managers are elected. If for some reason the current Manager fails, a different Manager can be elected, preserving service availability.
How can I make code Message driven?
It should be already. Messaging is a more stable, scalable to later requirements and more reliable; compared to other options. Messaging fits nicely with SOA and the above resiliency features. Further details for desirable attributes of a messaging system:
- Keep the messages themselves fairly small. This reduces likelihood for receiving half a message.
- Make messages idempotent 25, so duplicate messages can be detected/ avoided.
- Limit message sequencing requirements with careful design, so the message receivers have reduced validation requirements.
- A traditional RDBMS may not be a good solution for storing in-flight messages, outlined 26
- Further reading on messaging systems 27 28 29