Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality. Learn more →
Inai Alternatives
Similar projects and alternatives to inai
-
opentracing-javascript
Discontinued OpenTracing API for Javascript (both Node and browser). 🛑 This library is DEPRECATED! https://github.com/opentracing/specification/issues/163
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
OberonSystem
Modified version of the original from http://www.projectoberon.com/ for use with the Oberon IDE
-
axios
Discontinued Promise based HTTP client for the browser and node.js [Moved to: https://github.com/axios/axios] (by mzabriskie)
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
inai reviews and mentions
- An experiment structuring a Node.js application internally using REST principles
-
Objective-S: architecture-oriented language based on Smalltalk and Objective-C
This is useful! Thanks for writing this out. I find in-process REST intriguing as it stands a little in contrast with OOP techniques. One possibility I’ve with in-process REST is that it seems to make live patches feasible - more feasible than in erlang. I use the idea as the core of Inai - https://github.com/imaginea/inai ... so am curious to play with that aspect of ObjS.
-
Monolith First
A bit of a shameless plug, but really looking for feedback .. I've been experimenting with Inai [1][2], a framework that can help build modular microservice-like software with similar Dev team independence properties but can independently be built and deployed as a monolith or as separate services operationally. So far, I've had fun building an internal project at much higher speed than I've managed any similar project and had more fun doing it. I feel the idea (which is still nascent) has some merit, but would like to know what folks think.
[1] source - https://github.com/Imaginea/Inai
[2] blog post describing Inai - https://labs.imaginea.com/inai-rest-in-the-small/
-
Oberon OS Walkthrough
At some point, this would be come close to the AppleScript protocol or Symbian OS.
> So the drawing part of an application would just be a process that sends the screen/compositor process a message describing the state of its window as a tree, and receives messages for events in response.
I've been toying with an interpretation of this here - https://github.com/Imaginea/inai - and kind of having fun with it .. and even built a prototype internal app using it. Super early stage and so stuff won't necessarily make sense at the outset .. or possibly ever. Thoughts welcome though.
> A big advantage is it makes the semantics of composing GUIs a lot more reasonable "replace this leaf of my tree with this other process' tree" ...
The "dom" service in Inai pretty much feels like that. I felt like an idiot to try and (for lack of a better expression) REST-ify the DOM, but it seemed to work to my surprise.
> An application could also "proxy" for a widget, including over a network link, so you get fairly simple network transparency this way too.
.. yeah due to the "REST" nature, this becomes pretty straightforward.
-
A note from our sponsor - InfluxDB
www.influxdata.com | 24 Apr 2024
Stats
Imaginea/inai is an open source project licensed under Apache License 2.0 which is an OSI approved license.
The primary programming language of inai is JavaScript.
Sponsored