new architecture incorporating functional programming

[Gopi Suvanam]

Dear All,
We have been working on a new architecture for our APIs. we develop financial analytics apps. We felt that RESTful architecture does not help us in making apps efficiently. As a result we developed a new archetcture incporating conecpts of REST and functional programming. Below is a link of a paper on the same. Would love to have the community's comments on the same.

https://arxiv.org/ftp/arxiv/papers/1607/1607.05075.pdf

Regards
Gopi

[Chris Mullins]

Interesting. A few questions:

> Although Lambda Machine might seem similar to remote procedure 

> calls (RPC), it is different in significant ways.

It seems very RPC like, with some restrictions that would naturally fall out from Lambdas. 

> Unlike RPC, the proposed lambda machine can interact with

> a client without the client getting strongly coupled to the server. 

Try as I might, I don't understand how this is happening. When I look at SOAP, REST, OData Actions, or even Graph Query stuff, I don't understand how this provides a different coupling model than the others.  

> The calls to Lambda Machine can happen over HTTP.

This is true for lots of systems. The wold runs over HTTP. Heck, If I tried I could tunnel DCOM or CORBA over HTTP these days. :) 

> Most importantly the Lambda Machine does not change the

> state of the system after a call. In other words if the lambda

> machine is sent two subsequent requests with same data,

> the result will be same

It's non-mutating and idempotent, which is always a good thing for reads! :) 

In what way is this different from a standard GET request, or a (logical) SEARCH request issues via an HTTP POST? 

Cheers,

Chris

[Gopi Suvanam]

Hi Firstly thanks for thoroughly going through the article.. much appreaciated..

It seems very RPC like, with some restrictions that would naturally fall out from Lambdas.

The constraints are what make it unique. especially statelessness and hypermedia.. So for example /lib/module can contain all the functions in the module as a list. this makes the API easy to use..
 

Try as I might, I don't understand how this is happening. When I look at SOAP, REST, OData Actions, or even Graph Query stuff, I don't understand how this provides a different coupling model than the others.  

REST is already part of the architecture.. the closest anology could be OData Actions. The diference between OData and FAST is the difference betwee object oriented programming and functional programming.. OData Actions do not guarantee statelessness (although OData functions do not change the state). Odata actions are mebedded in resources/objects.. Where as the FAST architecture segregates data and computation explicitly.. Thus the data can be exposed as a REST API by one entity and the computation can be done by another entity..

 

This is true for lots of systems. The wold runs over HTTP. Heck, If I tried I could tunnel DCOM or CORBA over HTTP these days. :) 

So true.. But I'm surprised how many non-extarnal facing applications still do not use HTTP.. Databases are classic examples.. ideally DBs should run as HTTP servers.. but thats beside the point.. anyways agree HTTP is a trivial advantage

 

It's non-mutating and idempotent, which is always a good thing for reads! :) 

Statelessness is a great advantages.. but the architecture also supports state by running a restful server parallelly..

In what way is this different from a standard GET request, or a (logical) SEARCH request issues via an HTTP POST? 

Through simple POST requests one is not sure if there is a state change or not.. Of crouse we are doing the implementation of the architecture through GET and POST only, but we are putting additional constraints on top of it.. In addition to regular HTTPm methods we think if we add Map, Apply and Filter methods there could be more functionality but thats too much of effort so we are taking a short cut of adding the verb to_do as part of parameters

Regards
Gopi



 

[Gopi Suvanam]

the architecture is still evolving as we keep using it to implement our products.. so any suggestions & recommendations are super welcome..

[Filippos Vasilakis]

First of all, congrats for describing the architecture in a 'paper' format and not in a yet another blog post. Seems interesting idea but not explained in detail.

I would like more explanation on the analytics example:

"Traditional RESTful architecture can easily take care of data related operations. But it fails when it comes to functional calls and requests for some analysis to be performed on the data. This is especially true for realtime analytics. For example if one has to filter out all the users based on certain constraints on age/gender etc. Such a querying system is tough to implement using simple RESTful architecture. Whereas it can be easily implemented using a combination of REST and functional approach. Hence for most analytics apps, FAST architecture is most suitable on the server side"

How functional calls would be helpful here ?

One thing that I (personally) fail to gasp is the chained calls: applying a response to another resource. There have been some ideas on that in REST as well but I guess they failed due to complexity. Can you give me an example that this chaining would be super helpful (and thus it would outweight the complexity) ? Because I fear that if  a client needs to instruct the part (server or client is DS) to chain a call then it's a bad design.

[Filippos Vasilakis]

Maybe I don't understand these parts because I have none knowledge in functional programming :)

[Gopi Suvanam]

Hi a paper format is useful for discussions especially if it is still an evolving idea..

Regarding use of functional calls in analytics, we regularly require large amounts of data to be processed and giving out some analytical output (lets say a groupby, a count or a statitical model). We dont want to couple this functionality with data. we want to keep data management segregated from computation. At the same time we want to give developers the ability to call any particular function on any set of data (of course the functions should be able to handle that..) this is where a combination of REST and functional programming helps.

for chained calls right now we are implementing everything through standard rest methods, it will be too much of distruption to add new methods and new parameters/format.. so we are introducing special query formats.. for example:

1. uri: this query parameter will take the data from a uri. the data then will be used in a function call.. other alternative approach we are taking is instead of taking special parameters the regular parameters can embed a uri by some escape characters like {{}}

2. to_uri: this is uri where the result of function call can be posted to

3. to_do: this implements special functional programming features viz. map, reduce and filter

we have built two applications around this architecture: 1. a robo-analytics app (an application that generates automated insights from a dump of data) 2. a financial calculator.. that can do a range of financial calculations starting from simple present value to exotic pricing..

hope that helps..

Regards

--
You received this message because you are subscribed to a topic in the Google Groups "API Craft" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/api-craft/m_KxwfBZo4c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to api-craft+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

--

https://drive.google.com/file/d/0B6O3ziZlKtd1aVBDREZocEV6ZEk/view

[Owen Rubel]

You should NOT have to do this through secondary responses; this should ALL take place in ONE REQUEST/ONE RESPONSE. You have to abstract the communication logic from the business logic. Once done you get 85%-150% greater performance.

On Thursday, October 6, 2016 at 4:55:01 AM UTC-7, Gopi Suvanam wrote: