Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is RESTFul Paradigm a Type of FFI (Foreign Function Interface)?

news.ycombinator.com

Post reply on HN
Print view View original

11–19 of 19 posts

Re: Is RESTFul Paradigm a Type of FFI (Foreign Function Interface)?

#11

Post by Waterluvian »

oaiey wrote: post #10

Ivory to tower statement: Architecture calls these components and connectors. A component can be something as small as a function or as big as a monolith. A connector specifies the connection and its attributes between two components. However, connectors can be of any form. They can be based on memory/processor (like local function calls), based on network protocols (like http calls), databases (a system a drops a re…

Your comment just gave me a brain thing and it’s probably obvious to smart people but here goes:

Connectors are what really matter when it comes to de-risking a project. They’re where you delineate things that are nice to haves. They give you escape hatches (like your data popping out of one component in a format that can be edited by hand, stored, loaded). They let you more trivially replace and upgrade pieces.

Components aren’t all that interesting. They might be a place for optimization but mostly are just implementation detail.

And at any scale I think about in my work, there’s components and connectors. Whether an HTTP API or a function signature.

Is this what the Smalltalk guy meant by it being all about message passing?

Re: Is RESTFul Paradigm a Type of FFI (Foreign Function Interface)?

#12

Post by mpweiher »

Waterluvian wrote: post #11
oaiey wrote: post #10

Ivory to tower statement: Architecture calls these components and connectors. A component can be something as small as a function or as big as a monolith. A connector specifies the connection and its attributes between two components. However, connectors can be of any form. They can be based on memory/processor (like local function calls), based on network protocols (like http calls), databases (a system a drops a re…

Your comment just gave me a brain thing and it’s probably obvious to smart people but here goes: Connectors are what really matter when it comes to de-risking a project. They’re where you delineate things that are nice to haves. They give you escape hatches (like your data popping out of one component in a format that can be edited by hand, stored, loaded). They let you more trivially replace and upgrade pieces. Comp…

> Connectors are what really matter when it comes to de-risking a project.

Yes, they define the architectural style and thus what architectures you can build.

This is getting more and more important because the default architectural style of the vast bulk of our programming languages, call/return, is unsuited for build most of the types of systems we are trying to build.

> Components aren’t all that interesting.

Yes and no. The architecture is defined by the connectors, but in day-to-day programming, your functionality is going to be mostly in the components.

> And at any scale I think about in my work, there’s components and connectors

Yes.

Which is why I created an architecture-oriented programming language that lets you deal with components and connectors

http://objective.st

> Is this what the Smalltalk guy meant by it being all about message passing?

I believe that to be largely the case.

Re: Is RESTFul Paradigm a Type of FFI (Foreign Function Interface)?

#13

Post by oaiey »

Waterluvian wrote: post #11
oaiey wrote: post #10

Ivory to tower statement: Architecture calls these components and connectors. A component can be something as small as a function or as big as a monolith. A connector specifies the connection and its attributes between two components. However, connectors can be of any form. They can be based on memory/processor (like local function calls), based on network protocols (like http calls), databases (a system a drops a re…

Your comment just gave me a brain thing and it’s probably obvious to smart people but here goes: Connectors are what really matter when it comes to de-risking a project. They’re where you delineate things that are nice to haves. They give you escape hatches (like your data popping out of one component in a format that can be edited by hand, stored, loaded). They let you more trivially replace and upgrade pieces. Comp…

Connectors cover many non functional requirement attributes which like you point out de risk the project.

Components and their behaviors is where the functional requirements are and also many non functional requirements are handled. There is tons of architecture and design space when it comes to e.g. the SOLID patterns (applied to components not objects) and the onion architecture comes into play. So there is tons of interesting stuff to do with components.

About derisking: the core pillar of architecture when it comes to Microservices is finding the right bounded context. This massively de-risk projects as well. It is not so much technical architecture like the mentioned connectors but analysis of the requirements.

Architecture on that level is very interesting.

Re: Is RESTFul Paradigm a Type of FFI (Foreign Function Interface)?

#14

Post by dgb23 »

Waterluvian wrote: post #11
oaiey wrote: post #10

Ivory to tower statement: Architecture calls these components and connectors. A component can be something as small as a function or as big as a monolith. A connector specifies the connection and its attributes between two components. However, connectors can be of any form. They can be based on memory/processor (like local function calls), based on network protocols (like http calls), databases (a system a drops a re…

Your comment just gave me a brain thing and it’s probably obvious to smart people but here goes: Connectors are what really matter when it comes to de-risking a project. They’re where you delineate things that are nice to haves. They give you escape hatches (like your data popping out of one component in a format that can be edited by hand, stored, loaded). They let you more trivially replace and upgrade pieces. Comp…

Connectors are the primary manifestation of software complexity. This doesn’t mean connectors are bad. They are necessary.

If they are uniform and well understood, then you get to reason about them more easily. That is part of the idea of „the smalltalk guy“ that you refer to. Hint: there is not just one guy.

https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....

Re: Is RESTFul Paradigm a Type of FFI (Foreign Function Interface)?

#15

Post by Kinrany »

kazinator wrote: post #4

You are correct. When you develop a FFI, you solve many of the same issues that are solved in RPC (remote procedure calls). When you convert Lisp objects to C objects and vice versa across the call, this is very similar to marshalling and unmarshalling remote procedure call arguments. The different representations and memory management of the objects are such that the two domains are often like different machines. If…

There should be an interface description language that works equally well for FFI and RPC. It could be agnostic of the transport mechanism and the type system used to describe messages, and merely enumerate possible methods in a hierarchical (and composable) way.

Re: Is RESTFul Paradigm a Type of FFI (Foreign Function Interface)?

#17

Post by kazinator »

Kinrany wrote: post #15
kazinator wrote: post #4

You are correct. When you develop a FFI, you solve many of the same issues that are solved in RPC (remote procedure calls). When you convert Lisp objects to C objects and vice versa across the call, this is very similar to marshalling and unmarshalling remote procedure call arguments. The different representations and memory management of the objects are such that the two domains are often like different machines. If…

There should be an interface description language that works equally well for FFI and RPC. It could be agnostic of the transport mechanism and the type system used to describe messages, and merely enumerate possible methods in a hierarchical (and composable) way.

Where we see a difference between the two is that FFIs are designed to be able to directly call all sorts of uncooperative code which is oblivious to FFI, without adding any wrapper code to it. FFI languages have a lot of detail because of that, for describing binary types, calling conventions, memory management ownership and such. (You can use the binary types system of the FFI even if you aren't calling any foreign functions; e.g. to parse a header in a binary file.)

Whereas in RPC, we usually control both sides of the call. If there is third party code, we will glue to that from the server-side RPC stub. Even if this is a RPC based on a lower level language like C, it doesn't have to have the generality of describing any C type or function; you design your RPC API to the limitations of the RPC system. E.g. if, say, it cannot pass structures by value, you don't do that in the API. If it doesn't handle bit fields in structures, you likewise don't feature such a thing in your API.

Re: Is RESTFul Paradigm a Type of FFI (Foreign Function Interface)?

#18

Post by gavinray »

Kinrany wrote: post #15
kazinator wrote: post #4

You are correct. When you develop a FFI, you solve many of the same issues that are solved in RPC (remote procedure calls). When you convert Lisp objects to C objects and vice versa across the call, this is very similar to marshalling and unmarshalling remote procedure call arguments. The different representations and memory management of the objects are such that the two domains are often like different machines. If…

There should be an interface description language that works equally well for FFI and RPC. It could be agnostic of the transport mechanism and the type system used to describe messages, and merely enumerate possible methods in a hierarchical (and composable) way.

There is, it's called COM, and Windows as an operating system and ecosystem is built on top of it. (Though COM as a specification is not limited to Windows)

The language you use for defining the types is creatively named "Interface Definition Language (IDL)", and the "MIDL" compiler converts the interface definitions into C & C++ types and objects which can be used. Both via in-process/inter-process function calls, or via RPC/DCOM (Distributed COM).

https://en.wikipedia.org/wiki/Component_Object_Model#DCE/RPC...

  "As a cross-language component model, COM relies on an interface definition language, or IDL, to describe the objects and associated functions. The COM IDL is based heavily on the feature-rich DCE/RPC IDL, with object-oriented extensions. Microsoft's own implementation of DCE/RPC, known as MSRPC, is heavily used as the primary inter-process communication mechanism for Windows NT services and internal components, making it an obvious choice of foundation."

  "DCOM (Distributed COM) extended the reach of COM from merely supporting a single user with separate applications communicating on the Windows desktop, to activating objects running under different security contexts, and on different machines across the network. With this were added necessary features for configuring which users have authority to create, activate and call objects, for identifying the calling user, as well as specifying required encryption for security of calls."
If you want to learn more about this (it's an incredibly powerful concept that has a wide range of uses and is very much still used today), my recommendation would be:

1. The book: "Essential COM (1997)" by Don Box, one of the architects of COM at Microsoft in the 90s

  https://www.amazon.com/Essential-COM-Don-Box/dp/0201634465
2. The online tutorial "COM in plain C", which is one of the only (it might even be, like, THE only) resources for learning how COM actually works, since generally you use C++ frameworks to interact with it and they cover up all the details.

  https://www.codeproject.com/Articles/13601/COM-in-plain-C
---------

Disclaimer: I'm no expert in COM myself, I'm also working through these same learning materials.

I have a strong interest in FFI/Interop between languages and so have been working through things like "What is an ABI, conceptually?", understanding the C++ Itanium ABI, reading about vtable's, manually emulating C++ classes and class-inheritance with C structs of function pointers (vtables) etc.

COM is foundational here so it's the thing on my list atm. Hope you find this useful!

Re: Is RESTFul Paradigm a Type of FFI (Foreign Function Interface)?

#19

Post by Kinrany »

gavinray wrote: post #18
Kinrany wrote: post #15

Earlier quoted context omitted.

There should be an interface description language that works equally well for FFI and RPC. It could be agnostic of the transport mechanism and the type system used to describe messages, and merely enumerate possible methods in a hierarchical (and composable) way.

There is, it's called COM, and Windows as an operating system and ecosystem is built on top of it. (Though COM as a specification is not limited to Windows) The language you use for defining the types is creatively named "Interface Definition Language (IDL)" , and the "MIDL" compiler converts the interface definitions into C & C++ types and objects which can be used. Both via in-process/inter-process function calls,…

Thank you!

Yeah, I also feel like it's important. Too much time is wasted on X-lang wrappers for Y-lang libraries.

Post reply on HN