5 ms·

Thank you very much! this is very helpful for me. I'm making https://epiphany.pub https://epiphany.pub , it also needs to run users' code. I thought iframe was

Thank you very much! this is very helpful for me. I'm making https://epiphany.pub https://epiphany.pub , it also needs to run users' code. I thought iframe was the only viable way to run third parties' untrusted code, I have never heard of Realms shim. I will looking into it!

tyleo 7y ago
Yeah, this technology looks great. I'm working on https://devev.com https://devev.com which will allow users to import JavaScript/TypeScript libraries and use their exported functions in flow charts. I'm pretty early stage but I got a desktop app running last night. I've got some documentation work to do but I have a PoC of Devev as a webapp which I'd like to deploy soon. I haven't resolved all of the security issues yet so this article is a goldmine for me.
- cameronbrown 7y ago
  Your product's concept looks great. I've used UE4 Blueprints for high-level prototyping while dropping down to C++ for stuff that needs tunes performance - it's insanely powerful combination. The web could use something like that.
- crdrost 7y ago
  Awesome! There is a way to avoid some of the pain discussed in the article with iframes as well, and it uses techniques from domain-driven design as applied to microservice architectures. So in this analogy the iframes are your "browser microservices" and the main app is also a sort of microservice and they all have to communicate with each other. The basic idea there is that most microservice architectures are actually subtly monolithic because they have direct communication via The Database. Basically whenever you have a shared database you have a form of tight coupling which defeats the point of microservices. So in DDD, you deal with communications difficulties by creating these Bounded Contexts where a word means one given thing; applying that here with a notion that "meaning" is controlled by The Database, you want to transition to "miniliths" where a set of services has its own local database. Then your two miniliths talk to each other by passing messages back and forward; generally you want these messages to be Events ("this happened over here and I thought you should know about it but I don't want a response") rather than Requests (which invite responses and then you have to ask questions about what if the response is not what you expected or it was not received, etc., what happened in the middle?). You don't have to go the whole way to an Event Sourced Architecture (where your model is entirely determined by a sequence of received Events which have been stored in a database and can be used to "rehydrate" that model from scratch at any given time) to get about 80% of the value of the message-passing. So translated to this context, basically what you have is a model of your system (possibly simplified) that you keep inside of the iframe and a model you keep in the app; the message bus communicates changes between the two but it seldom needs to serialize the whole structure at any given time. You allow plugins to interact with the in-iframe-model and it sends events "hey this happened" to the outside world, which has to respond to those events by updating its own data model. But fundamentally you have these two separate data models for the thing and they are being held together by a promise of eventual consistency through message-passing the diffs to the structure.
  - lioeters 7y ago
    Really nice explanation of how domain-driven design can inform the architecture of browser-based plugins/microservices/miniapps. It makes sense to separate concerns by passing messages between isolated layers, and I can see how it could apply to other domains similarly. To summarize for my own understanding: - "Minilith" (love the term!) with a model of your system (possibly simplified) that you keep inside of the iframe - App with its own model - The message bus communicates changes between the two but it seldom needs to serialize the whole structure at any given time.. Eventual consistency through message-passing the diffs For some applications where I want to give users scripting capability, I've been thinking of a simplified DSL with its own "VM", passing some isolated objects from the host app to render results. The architecture you described, of "miniliths" with their own state (or in-memory database) passing messages to the host (or to each other) sounds like a sane and flexible approach.
  - sverhagen 7y ago
    > Basically whenever you have a shared database you have a form of tight coupling which defeats the point of microservices. With all the different interpretations of what is a microservice, a common one is that having a shared database makes it not a microservices architecture. But yeah, people call them that regardless.
- rizky05 7y ago
  This looks similar to node-red
lioeters 7y ago
Thank you for sharing your project, Epiphany. The introduction article [0] does a great job of explaining its motivation and purpose. I found myself nodding along to the points made, and the whole concept of a social publishing platform for interactive content. [0] https://shi-yan.github.io/epiphany/ https://shi-yan.github.io/epiphany/
- billconan 7y ago
  Thank you for liking it. I'm looking for feedback if you'd like to try it. I will appreciate it. here are some interactive examples: https://epiphany.pub/post?refId=2684bc94f9fcb9ffe637ebfbeba2af8c797c6ad9a66181026ee4bd3806b6f211 https://epiphany.pub/post?refId=2684bc94f9fcb9ffe637ebfbeba2... https://epiphany.pub/post?refId=3e123914a88818452d7f2c24fd8ad079ad621a5e94f514cca5598fb9479d5342 https://epiphany.pub/post?refId=3e123914a88818452d7f2c24fd8a... I'm trying to make more.
  - lioeters 7y ago
    Sure, here are some first impressions from someone who has no real experience with Jupyter, Observable, etc. :) I'm really amazed at the seamless reading and editing experience. This is very well-made, I can see it must have been quite an effort to make it feel so effortless. The ability for a code block to provide a "mini UI" is perfect. A reader can tweak controls and see immediate visual feedback, in the form of graphs, algorithms with variables.. One control I missed was a stop button - for the second example, I wanted to pause the generation of the 3D city/terrains, to continue reading. I liked the dotted blue vertical lines to indicate "block focus", to see what it contains when I click edit. While dragging a block, I had some difficulty crossing over another block which was long - in fact, I couldn't swap them, since dragging down didn't trigger the scroller to start. From what I know, this relates to the "center of gravity" during drag, whether the dragged block goes under another one. As for the scroller, maybe it's using a range that needs to be bigger, so that when I drag a block "below" the bottom of the screen, it starts scrolling. Anyway, lots of fun and impressive work! This looks very useful for educational purposes. You're really hitting a sweet spot with the concept - (just iterating on this phrase to get my head around it), a social publishing platform for interactive content. Great execution, and I'm looking forward to seeing it grow.

tyleo 7y ago

Yeah, this technology looks great. I'm working on https://devev.com https://devev.com which will allow users to import JavaScript/TypeScript libraries and use their exported functions in flow charts. I'm pretty early stage but I got a desktop app running last night. I've got some documentation work to do but I have a PoC of Devev as a webapp which I'd like to deploy soon. I haven't resolved all of the security issues yet so this article is a goldmine for me.

cameronbrown 7y ago
Your product's concept looks great. I've used UE4 Blueprints for high-level prototyping while dropping down to C++ for stuff that needs tunes performance - it's insanely powerful combination. The web could use something like that.
crdrost 7y ago
Awesome! There is a way to avoid some of the pain discussed in the article with iframes as well, and it uses techniques from domain-driven design as applied to microservice architectures. So in this analogy the iframes are your "browser microservices" and the main app is also a sort of microservice and they all have to communicate with each other. The basic idea there is that most microservice architectures are actually subtly monolithic because they have direct communication via The Database. Basically whenever you have a shared database you have a form of tight coupling which defeats the point of microservices. So in DDD, you deal with communications difficulties by creating these Bounded Contexts where a word means one given thing; applying that here with a notion that "meaning" is controlled by The Database, you want to transition to "miniliths" where a set of services has its own local database. Then your two miniliths talk to each other by passing messages back and forward; generally you want these messages to be Events ("this happened over here and I thought you should know about it but I don't want a response") rather than Requests (which invite responses and then you have to ask questions about what if the response is not what you expected or it was not received, etc., what happened in the middle?). You don't have to go the whole way to an Event Sourced Architecture (where your model is entirely determined by a sequence of received Events which have been stored in a database and can be used to "rehydrate" that model from scratch at any given time) to get about 80% of the value of the message-passing. So translated to this context, basically what you have is a model of your system (possibly simplified) that you keep inside of the iframe and a model you keep in the app; the message bus communicates changes between the two but it seldom needs to serialize the whole structure at any given time. You allow plugins to interact with the in-iframe-model and it sends events "hey this happened" to the outside world, which has to respond to those events by updating its own data model. But fundamentally you have these two separate data models for the thing and they are being held together by a promise of eventual consistency through message-passing the diffs to the structure.
- lioeters 7y ago
  Really nice explanation of how domain-driven design can inform the architecture of browser-based plugins/microservices/miniapps. It makes sense to separate concerns by passing messages between isolated layers, and I can see how it could apply to other domains similarly. To summarize for my own understanding: - "Minilith" (love the term!) with a model of your system (possibly simplified) that you keep inside of the iframe - App with its own model - The message bus communicates changes between the two but it seldom needs to serialize the whole structure at any given time.. Eventual consistency through message-passing the diffs For some applications where I want to give users scripting capability, I've been thinking of a simplified DSL with its own "VM", passing some isolated objects from the host app to render results. The architecture you described, of "miniliths" with their own state (or in-memory database) passing messages to the host (or to each other) sounds like a sane and flexible approach.
- sverhagen 7y ago
  > Basically whenever you have a shared database you have a form of tight coupling which defeats the point of microservices. With all the different interpretations of what is a microservice, a common one is that having a shared database makes it not a microservices architecture. But yeah, people call them that regardless.
rizky05 7y ago
This looks similar to node-red

lioeters 7y ago

Thank you for sharing your project, Epiphany. The introduction article [0] does a great job of explaining its motivation and purpose. I found myself nodding along to the points made, and the whole concept of a social publishing platform for interactive content. [0] https://shi-yan.github.io/epiphany/ https://shi-yan.github.io/epiphany/

billconan 7y ago
Thank you for liking it. I'm looking for feedback if you'd like to try it. I will appreciate it. here are some interactive examples: https://epiphany.pub/post?refId=2684bc94f9fcb9ffe637ebfbeba2af8c797c6ad9a66181026ee4bd3806b6f211 https://epiphany.pub/post?refId=2684bc94f9fcb9ffe637ebfbeba2... https://epiphany.pub/post?refId=3e123914a88818452d7f2c24fd8ad079ad621a5e94f514cca5598fb9479d5342 https://epiphany.pub/post?refId=3e123914a88818452d7f2c24fd8a... I'm trying to make more.
- lioeters 7y ago
  Sure, here are some first impressions from someone who has no real experience with Jupyter, Observable, etc. :) I'm really amazed at the seamless reading and editing experience. This is very well-made, I can see it must have been quite an effort to make it feel so effortless. The ability for a code block to provide a "mini UI" is perfect. A reader can tweak controls and see immediate visual feedback, in the form of graphs, algorithms with variables.. One control I missed was a stop button - for the second example, I wanted to pause the generation of the 3D city/terrains, to continue reading. I liked the dotted blue vertical lines to indicate "block focus", to see what it contains when I click edit. While dragging a block, I had some difficulty crossing over another block which was long - in fact, I couldn't swap them, since dragging down didn't trigger the scroller to start. From what I know, this relates to the "center of gravity" during drag, whether the dragged block goes under another one. As for the scroller, maybe it's using a range that needs to be bigger, so that when I drag a block "below" the bottom of the screen, it starts scrolling. Anyway, lots of fun and impressive work! This looks very useful for educational purposes. You're really hitting a sweet spot with the concept - (just iterating on this phrase to get my head around it), a social publishing platform for interactive content. Great execution, and I'm looking forward to seeing it grow.