[dart-misc] Request for feedback on Dart Summit talk proposal

[Robert Åkerblom-Andersson]

Hi,

*Background*
I plan to attend the Dart Developer Summit later this year, I have been
thinking that it would be fun to contribute with a talk. Now the tricky
part is coming up with a good proposal, I thought I'd ask for feedback here
to see what people think. I would love to get some feedback on my proposal,
both positive and negative. This is not necessarily the exact abstract
version that is required for the official application, look at it as more
of an informal check of interest. Based on potential feedback I will decide
if it feels worth it to sending in a proposal or not.

Some of you reading this might recognize me from other interactions around
Dart, online or at the Dart summit last year, but for others a short
personal introduction might be relevant in relation to the proposal, plus
some technical background. Personally I have been involved with Dart since
around 2012, I got the idea of building a PaaS for Dart around the time I
discovered Dart. To make a long story short building a PaaS from the ground
up takes a looong time, it was called DartVoid in the early days and it has
been through several iterators and rewrites at different layers to later
evolve into a new service called Sourcevoid <https://www.sourcevoid.com/>
that went live this summer. We use Dart quite a lot at Sourcevoid, here are
some examples;

- Our homepage is server side rendered using Dart, most content is written
in markdown, then live rendered and cached in memory by the server, on
mobile the menu animation is done using client side Dart
- Our main customer facing app is a Dart SPA app
(https://cloud.sourcevoid.com), it in turn uses a client library written in
Dart to talk to a Dart API
- The Dart API server implements certain functionality on it's own while
most requests are translated via an internal Dart to Go RPC implementation.
The core functionality of the PaaS platform such as scheduling and managing
containers and so on and so forth is implemented in Go. Why Go? At the time
when this implementation was started Dart had not reach 1.0 yet, plus Go is
a little better suited for more system level programming like this while
Dart shines in other areas, I should also add that sometimes I miss certain
higher level Dart features when developing in Go.
- We have a Dart CLI app that is under development that will be released
later this fall, it will reuse the Dart client library and models that the
browser UI uses today, combining our existing client library with
Dart's args package makes it's a very nice developer experience. The plan
is to release this sometime between now and the Dart summit, it will
implement a subset of the UI's functionality at start and get more complete
over time.

*Proposal discussion: Dart API Clients Everywhere*
I thought it could be interesting to see an architecture overview of how we
use Dart API clients "everywhere", that is reusing the same API client
library both in the browser and on desktop/server and how we how we share
code between these different platforms. I was thinking that I could start
with an architecture overview to see how the API and backend services
connects to each other, basically some visual representation of the
architecture so you get a feel for the system. Then my idea was to go a
little deeper into the client API library and CLI app, maybe show how we
use the http package on both the browser and the desktop, not a huge thing
but there are small differences because of dart:io vs dart:html. Maybe look
at a little bit of code, to see how the CLI app works and how you can build
CLI apps quite easily with the args package. We don't have plans to release
any mobile app at this point, but if the audience / you reading this would
find it interesting I could maybe put together a small prof of concept
Flutter app as well, since our API client is built on the http package I
think it should not be too much work to get our client lib to work on
Flutter as well (they have their own implementation of the http package,
but I think it should work similar to how we use the http package for the
dart:html vs dart:io implementations).

*Feedback*
1. Overall, would you like to see a talk like this? (Yes/No)
2. Was it something in particular that you think I should add, remove or
change? (Keep in mind that this is not a formal abstract proposal but still)
3. The Flutter thing, would that be interesting? (Yes/No)

Sincerely, Robert

[Daniel Davidson]

Robert,

Thanks for this and yes to both 1) and 3).

I would be interested in hearing about the "why" behind "I got the idea of
building a PaaS ...". Is this part-time/avocation or a vocation?
How do you fund it, etc? Is it or are there plans to go open source and
why?
Don't know how appropriate those questions are for a technical talk though.

Thanks,
Dan


On Sunday, August 21, 2016 at 6:28:33 AM UTC-5, Robert Åkerblom-Andersson

Post by Robert Åkerblom-Andersson
Hi,
*Background*
I plan to attend the Dart Developer Summit later this year, I have been
thinking that it would be fun to contribute with a talk. Now the tricky
part is coming up with a good proposal, I thought I'd ask for feedback here
to see what people think. I would love to get some feedback on my proposal,
both positive and negative. This is not necessarily the exact abstract
version that is required for the official application, look at it as more
of an informal check of interest. Based on potential feedback I will decide
if it feels worth it to sending in a proposal or not.
Some of you reading this might recognize me from other interactions around
Dart, online or at the Dart summit last year, but for others a short
personal introduction might be relevant in relation to the proposal, plus
some technical background. Personally I have been involved with Dart since
around 2012, I got the idea of building a PaaS for Dart around the time I
discovered Dart. To make a long story short building a PaaS from the ground
up takes a looong time, it was called DartVoid in the early days and it has
been through several iterators and rewrites at different layers to later
evolve into a new service called Sourcevoid <https://www.sourcevoid.com/>
that went live this summer. We use Dart quite a lot at Sourcevoid, here are
some examples;
- Our homepage is server side rendered using Dart, most content is written
in markdown, then live rendered and cached in memory by the server, on
mobile the menu animation is done using client side Dart
- Our main customer facing app is a Dart SPA app (
https://cloud.sourcevoid.com), it in turn uses a client library written
in Dart to talk to a Dart API
- The Dart API server implements certain functionality on it's own while
most requests are translated via an internal Dart to Go RPC implementation.
The core functionality of the PaaS platform such as scheduling and managing
containers and so on and so forth is implemented in Go. Why Go? At the time
when this implementation was started Dart had not reach 1.0 yet, plus Go is
a little better suited for more system level programming like this while
Dart shines in other areas, I should also add that sometimes I miss certain
higher level Dart features when developing in Go.
- We have a Dart CLI app that is under development that will be released
later this fall, it will reuse the Dart client library and models that the
browser UI uses today, combining our existing client library with
Dart's args package makes it's a very nice developer experience. The plan
is to release this sometime between now and the Dart summit, it will
implement a subset of the UI's functionality at start and get more complete
over time.
*Proposal discussion: Dart API Clients Everywhere*
I thought it could be interesting to see an architecture overview of how
we use Dart API clients "everywhere", that is reusing the same API client
library both in the browser and on desktop/server and how we how we share
code between these different platforms. I was thinking that I could start
with an architecture overview to see how the API and backend services
connects to each other, basically some visual representation of the
architecture so you get a feel for the system. Then my idea was to go a
little deeper into the client API library and CLI app, maybe show how we
use the http package on both the browser and the desktop, not a huge thing
but there are small differences because of dart:io vs dart:html. Maybe look
at a little bit of code, to see how the CLI app works and how you can build
CLI apps quite easily with the args package. We don't have plans to release
any mobile app at this point, but if the audience / you reading this would
find it interesting I could maybe put together a small prof of concept
Flutter app as well, since our API client is built on the http package I
think it should not be too much work to get our client lib to work on
Flutter as well (they have their own implementation of the http package,
but I think it should work similar to how we use the http package for the
dart:html vs dart:io implementations).
*Feedback*
1. Overall, would you like to see a talk like this? (Yes/No)
2. Was it something in particular that you think I should add, remove or
change? (Keep in mind that this is not a formal abstract proposal but still)
3. The Flutter thing, would that be interesting? (Yes/No)
Sincerely, Robert

[Robert Åkerblom-Andersson]

Hi Daniel,

Thanks for taking the time to comment, happy to hear that! Haha well, I
agree that I'm not sure if those are appropriate for a talk at the Dart
Summit, but I can try to give some insight here in this thread instead.

*Why?*
It's a bit of a long story this whole thing but I try to summarize a little
bit. I think it's easier to understand if you get some context, I started
to study electrical engineering / computer engineer at the University,
starting at the very low level of electronic and overtime worked my way up
the stack or so to speak from doing PCB design and programming MCU's/FPGA's
to a growing interest in computer science, or at least the practical side
of CS. As I learned more programming I also got very interested in
programming languages, also computer architecture and operating systems. So
much fun and interesting things to learn about. To get a better sense I
could mention my bachelor thesis, it was a bit overkill for a bachelor
thesis but I designed a Network on a chip (NoC) design specification
optimized for use on FPGAs. If I could have picked a "dream job" at the
time I was studying I would have wanted to build a new processor
architecture, or a programming language. Neither of these options felt very
realistic based on where I lived and the general state of the markets of so
to speak, both areas are mostly "good enough" that it's very hard to
introduce anything new and even if you would try it costs a lot of time and
money.

So... What can you do, around year 2012 in technology that is somehow
similar to these areas and at the same time where it's possible to
implement a business model that can support all the development effort?
Because I also thought starting a business would be fun, to not be
restricted to a single narrow engineering role and instead get the chance
to build something new. My answer? "*The cloud*"... I thought a good
alternative was to build a PaaS platform, although that idea did not really
come until after I had learned about Dart I think. I remember the first
time I saw a YouTube video from Google IO when they talked about App
Engine, long before I heard of Dart, and I have since always thought that
the technology behind it seemed very interesting, I think you can say that
I found the whole concept and design of a big system that manages all these
resources mostly autonomously very intriguing. If you think about it,
building a PaaS platform from the ground up is not that different from some
form of cross between computer architecture and an operating system,
although the components involved are somewhat different. It's not the same,
but maybe you can see the similar appeal. With this said, I did not get the
idea of building a PaaS until after I discovered Dart and I was not looking
for a reason to build a PaaS at the time either. I can not say exactly why
I got the idea, but I think it was the opportunist in me who saw so much
potential in the Dart programming language on both the client and the
server, and yet Google was focusing all their resources on Dart in the
browser. I guess it was that perceived window of opportunity that made me
get the idea and start the journey that has lead me to where I am today.

*From hobby project to venture funded company to today*
My involvement got more serious over time during a 2 year period from the
summer of 2012 and forward. Those first two years I more or less was
studying on paper to get financial aid and loan from the government while
in practice I was spending most of my time work on this project... Some of
the things I did in the very early days never made it into the wild or was
later replaced/redesigned. I did for example implemented an SCGI server for
Dart that was never released publicly long before Dart's http server came
alone, the release of the http server package of course made using SCGI
pointless (and having a built in http server is a better way to do it I
think). I also more or less implemented two different container
technologies on top of existing constructs on both Linux and FreeBSD to
later replace them with tooling around Docker containers to fix/improve
init, networking and storage of those instead (again, when I did my own
implementations Docker did not exists). It was not because Docker added
anything critical really, it was more about less maintenance and updating
the technology over time, there are of course various benefits of using the
"de facto standard", Docker in this case. I should add that at the end of
the summer / start of autumn 2012 a friend of mine joined me in this
project that would later evolve into a company, Andreas. During the summer
of 2014 Andreas and I got into a 3 month accelerator like program, we
basically got three months with pay to work on this project and pitch
afterwards to investors. Again skipping some details, we got that
investment at the end of 2014 and started working more officially with this
as a full time job at the end of that year even though in practice we had
been working full time for a longer period. Andreas later left the company
in June 2015, I will not go into details here but it was of course a little
sad that it ended up that way, but it was fun the time it lasted and we
went our separate ways on good terms. From last summer up until now I have
done loooots of development of the things described in the architecture
overview above, the homepage, the dart API server, the client side lib, the
RPC layer and many more things has been developed this last year, it
literately feels like the time is just flying away. Anyhow it's very nice
that the service is up now since the end of June and I have lots of new
interesting stuff in the pipeline for the future!

*Open source and business*
This is a topic that I have studied quite closely over the years, as this
post already has gotten a little bit out of hand I should try to keep it
short. There is no plans to open source the core technology at this time. I
would find it interesting and fun to do so, but I'm doubtful that it would
be a good move from a business point of view. In this particular case you
could also question the usefulness, as our system is designed for running
on a very big scale, certain design decisions involved might not be optimal
for a sort of single developer setup. It's a fairly big distributed system,
and with any such system there will always be lots and lots of trade offs,
because by nature you can't optimize for every use case. So yeah even if we
would open source everything, I'm not sure how useful the core system would
be, for most people I think it's most useful when packaged up and delivered
as a service.

Something that I am considering however, is to maybe open source the client
library to interface with the platform and maybe also whole CLI app. Those
pieces I feel could be more useful and also less "risky" for what it's
worth. I personally like the idea of a service that provides an open API
and an open source client lib even though the core remains closed behind an
API. Having the option to do some small custom things on your own I think
can be useful. I have not fully decided on this subject yet, but we'll see,
the client lib and CLI app might get open sourced. I have also played with
the idea of open sourcing the company website, not the SPA app but the www
site, not sure if it would be wise or useful but I have thought about it.

Cheers, Robert

Post by Daniel Davidson
Robert,
Thanks for this and yes to both 1) and 3).
I would be interested in hearing about the "why" behind "I got the idea of
building a PaaS ...". Is this part-time/avocation or a vocation?
How do you fund it, etc? Is it or are there plans to go open source and
why?
Don't know how appropriate those questions are for a technical talk though.
Thanks,
Dan
On Sunday, August 21, 2016 at 6:28:33 AM UTC-5, Robert Åkerblom-Andersson

Post by Robert Åkerblom-Andersson
Hi,
*Background*
I plan to attend the Dart Developer Summit later this year, I have been
thinking that it would be fun to contribute with a talk. Now the tricky
part is coming up with a good proposal, I thought I'd ask for feedback here
to see what people think. I would love to get some feedback on my proposal,
both positive and negative. This is not necessarily the exact abstract
version that is required for the official application, look at it as more
of an informal check of interest. Based on potential feedback I will decide
if it feels worth it to sending in a proposal or not.
Some of you reading this might recognize me from other interactions
around Dart, online or at the Dart summit last year, but for others a short
personal introduction might be relevant in relation to the proposal, plus
some technical background. Personally I have been involved with Dart since
around 2012, I got the idea of building a PaaS for Dart around the time I
discovered Dart. To make a long story short building a PaaS from the ground
up takes a looong time, it was called DartVoid in the early days and it has
been through several iterators and rewrites at different layers to later
evolve into a new service called Sourcevoid <https://www.sourcevoid.com/>
that went live this summer. We use Dart quite a lot at Sourcevoid, here are
some examples;
- Our homepage is server side rendered using Dart, most content is
written in markdown, then live rendered and cached in memory by the server,
on mobile the menu animation is done using client side Dart
- Our main customer facing app is a Dart SPA app (
https://cloud.sourcevoid.com), it in turn uses a client library written
in Dart to talk to a Dart API
- The Dart API server implements certain functionality on it's own while
most requests are translated via an internal Dart to Go RPC implementation.
The core functionality of the PaaS platform such as scheduling and managing
containers and so on and so forth is implemented in Go. Why Go? At the time
when this implementation was started Dart had not reach 1.0 yet, plus Go is
a little better suited for more system level programming like this while
Dart shines in other areas, I should also add that sometimes I miss certain
higher level Dart features when developing in Go.
- We have a Dart CLI app that is under development that will be released
later this fall, it will reuse the Dart client library and models that the
browser UI uses today, combining our existing client library with
Dart's args package makes it's a very nice developer experience. The plan
is to release this sometime between now and the Dart summit, it will
implement a subset of the UI's functionality at start and get more complete
over time.
*Proposal discussion: Dart API Clients Everywhere*
I thought it could be interesting to see an architecture overview of how
we use Dart API clients "everywhere", that is reusing the same API client
library both in the browser and on desktop/server and how we how we share
code between these different platforms. I was thinking that I could start
with an architecture overview to see how the API and backend services
connects to each other, basically some visual representation of the
architecture so you get a feel for the system. Then my idea was to go a
little deeper into the client API library and CLI app, maybe show how we
use the http package on both the browser and the desktop, not a huge thing
but there are small differences because of dart:io vs dart:html. Maybe look
at a little bit of code, to see how the CLI app works and how you can build
CLI apps quite easily with the args package. We don't have plans to release
any mobile app at this point, but if the audience / you reading this would
find it interesting I could maybe put together a small prof of concept
Flutter app as well, since our API client is built on the http package I
think it should not be too much work to get our client lib to work on
Flutter as well (they have their own implementation of the http package,
but I think it should work similar to how we use the http package for the
dart:html vs dart:io implementations).
*Feedback*
1. Overall, would you like to see a talk like this? (Yes/No)
2. Was it something in particular that you think I should add, remove or
change? (Keep in mind that this is not a formal abstract proposal but still)
3. The Flutter thing, would that be interesting? (Yes/No)
Sincerely, Robert