the proxy design pattern is a super useful one in @Java.
The idea behind a proxy is to make it more transparent to work with remote resources. They're all over the place in @Java and enterprise Java, in particular. I'm going to look at some of my favorite examples in this thread
Spring Integration supports messaging gateways through proxies: inject a reference to Cafe, invoke that method and a Message<T> with the payload Order gets sent on the orders MessageChannel (and then to anywhere ya like)
@SpringCloud has a popular integration with #OpenFeign. Invoke methods on an injected instance of ApiClient to send (and receive) HTTP payloads to the configured HTTP service.
@SpringData supports the concept of repositories, itself also a design pattern, using proxies. Here, clients can invoke methods on CustomerRepository to reactively persist, update, or read data in a SQL/NoSQL database.
@SpringCloud also supports some of the popular @Square OSS projects, including #Retrofit, which is a bit like #OpenFeign, except that it also supports asynchronous/reactive HTTP requests/responses:
And of course, we musn't forget the now decades old support in core Spring for remote service invocation using protocols like Hessian, Burlap, HTTP-Invoker, RMI, etc. Clients can inject a reference to CabBookingService to invoke methods on the remote endpoint.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I spent the weekend working on my little side project which I hope will benefit others: it's a much-improved version of the publication pipeline I used to build @ReactiveSpring
the ideal is that you point the pipeline to the Git repo with you @asciidoctor docs, and point it to the Git repos (zero or more) containing code you'd like to include, and it'll clone 'em all, then generate your book.
* screen PDF
* prepress PDF
* ePub
* Mobi
* HTML
You can take that prepress ready book to @AmazonPub KDP for print. You can take the ePub or Mobi to @leanpub for everything else. Preview the screen PDF or HTML for yourself.
Cryptography takes time on the CPU. It’s one of those things that blocks threads in a reactive application. You need to move that into an isolated thread pool (a Scheduler, in @ProjectReactor). 1/N
Token-based security schemes like OAuth help here because they reduce the frequency of cryptography. You only need to do encryption when you exchange long term credentials (username, password) for short term credentials (token). 2/n
Token-based authentication schemes like OAuth also give you a better security posture because they reduce the surface area for password exposure. Ideally, your app will only exchange the username and password once for a given user session. 3/n
1. : one API no matter what the application (SSE, WS, HTTP, Kafka, whatever) etc are all easily represented as Reactive Stream types. This greatly simplifies integration and composition of disparate services and data
2. Reactive APIs give me declarative, concise, deterministic ways to express complex, multithreaded algorithms. Remember: only one person TRULY understands how to write safe, concise multithreaded Java code... and it’s NOT you! Let the abstraction do the work
I love the new @SpringBoot 2.3 release. It's hard to pick any single thing or theme, but I love the features that make my software even more relevant on @kubernetesio and in the cloud.
one of the frustrating things about public IaaS like AWS and evergreen SaaS (even on-prem) like @pivotalcf is that you can't constrain the 'version' of the dependency. that is, AWS is going to evolve and it MIGHT break assumptions into your code from yesteryear. 1/N
This is fine when there's a robust CI/CD practice to continuously (daily, at worst?) confirm that things haven't broken and an on-call team able to respond to such changes. It gets complicated when you want to ramp down the team and reprioritize their efforts 2/N
The result is that organizations can't completely wash their hands of software anymore. Obviously, a mature discussion of operational responsibilities in 2018 includes ongoing security maintenance, and so I'm fine with the idea that there's a long tail for maintenance. 3/N
We released Spring @springframework 5 in September 2017. This was the first release to introduce new Reactive programming support to help build more robust, scalable services. It builds upon the @Pivotal@ProjectReactor project, our reactive streams compatible reactive runtime.
@springframework 5 also includes a net-new reactive web runtime (and even supports @netty_project). It even includes a new reactive web runtime component model (called Spring WebFlux)