What is missing before an 0.5.4/0.6.0 version can hit npm

Question

What is missing before an 0.5.4/0.6.0 version can hit npm

mikaelhm opened this issue 10 years ago · 23 comments

Awesome work on releasing synth-api 0.3.0 using the dependency injection!

I wanted to play with it, but realized that synth has not been released to npm yet, in a version that uses synth-api 0.3.0.

I assume it is because some work that is still missing. Is there anything I can do to help out?

Answer 1 · 2014-08-11T22:40:47.000Z

Good observation, thanks for raising this issue!

In my mind, this is what I want before releasing a new version of synth:

Update the templates to make use of DI.
Update the sample project in the specs to also make use of DI, so it's tested as part of synth (even though it's tested in synth-api).
Update the docs at synthjs.com to explain the DI system.
Update the tutorial at synthjs.com to include adding a user authentication system using DI.

Or do you think the default template should have user authentication out of the box? If so, what extra task should be added to the tutorial to demonstrate creating new services? Maybe adding a params service, which could then be used for the tweet posting mechanism?

Answer 2 · 2014-08-11T23:15:42.000Z

I am a little confused by this:

Or do you think the default template should have user authentication out of the box? If so, what extra task should be added to the tutorial to demonstrate creating new services? Maybe adding a params service, which could then be used for the tweet posting mechanism?

I assume you mean if we do not add authentication, how do we demonstrate creating a new service.
I don't think we need to include authentication in the tutorial/default template for now.

What if we added a username field, such that a tweet consists username and message.

We could then have a some validation service, validating the username, not login, just a validation of whether it is long enough or so. It could also verify the tweet, or do link-shorten.

Alternatively, we could add hashtag support, then we need some parser to grab the hashtags from the message, this parsing could be done in a service.

Answer 3 · 2014-08-11T23:15:45.000Z

I will start by doing this:

Update the templates to make use of DI.

Answer 4 · 2014-08-11T23:47:25.000Z

I like your idea of adding a hashtag parsing service.

I think the user authentication should be included in the template, preferably cookie based so it's seamless for the front end and works with data preloading.

I also feel like I should write a blog post announcing this awesome new feature, which means I should make a blog... Hmm.

Answer 5 · 2014-08-12T01:04:20.000Z

I have started working on this,
https://github.com/mikaelhm/synth/commits/master

How would you prefer the PR's? One big or in small pieces?

Update the sample project in the specs to also make use of DI, so it's tested as part of synth (even though it's tested in synth-api).

I have updated the current sample project. Should we create a test case that uses a service?

Answer 6 · 2014-08-12T01:18:02.000Z

I like your idea of adding a hashtag parsing service.

Actually, the current template is very tiny compared to your blurb, so I guess the concept is that the template is for users to get started, and the tutorial should get them somewhat closer to your blurbs example, correct?

I think the user authentication should be included in the template, preferably cookie based so it's seamless for the front end and works with data preloading.

Why would token-auth be a problem for preloading? The way that Synth is automatically calling the api when requesting a page?

I also feel like I should write a blog post announcing this awesome new feature, which means I should make a blog... Hmm.

Hah, I have heard go about the https://ghost.org/ or just create a post on https://medium.com

Answer 7 · 2014-08-12T02:29:14.000Z

How would you prefer the PR's? One big or in small pieces?

One would be best. Great work so far, it's hugely appreciated!

the tutorial should get them somewhat closer to your blurbs example, correct?

Yup!

Why would token-auth be a problem for preloading?

The token needs to be sent in a cookie for data preloading because the server needs to know who is making the request when the initial request is made. i.e. if you type in a URL into your browser like http://blurbs.synthjs.com/blurbs/123, then the server needs to know who you are before responding with the HTML. The browser can't auto-fill a custom header like X-Auth-Token, but it can auto-provide a cookie.

just create a post on https://medium.com

Do other projects do that? I have used medium before, but not for synth. I'm wonder if you can group posts by tags. It'd be annoying for someone wanting to read Synth blog posts to have to read through my other posts :)

Answer 8 · 2014-08-12T05:26:09.000Z

Do other projects do that? I have used medium before, but not for synth. I'm wonder if you can group posts by tags. It'd be annoying for someone wanting to read Synth blog posts to have to read through my other posts :)

I just created an account on medium.com to check, you can create a collection called synth or synthjs and you will then be the owner, you are then in control of everything that goes in that collection(see more in this post)

Answer 9 · 2014-08-12T05:28:01.000Z

Oh right, and people can submit articles too. That could be useful. I like that idea.

On Mon, Aug 11, 2014 at 10:26 PM, Mikael Møller notifications@github.com
wrote:

Do other projects do that? I have used medium before, but not for synth. I'm wonder if you can group posts by tags. It'd be annoying for someone wanting to read Synth blog posts to have to read through my other posts :)

I just created an account on medium.com to check, you can create a collection called synth or synthjs and you will then be the owner, you are then in control of everything that goes in that collection(see more in this post)

Reply to this email directly or view it on GitHub:
#59 (comment)

Answer 10 · 2014-08-12T05:35:00.000Z

My goal is to have an app done within the next two weeks. I hope be able to open source it.
In that case, if you do the medium collection, I could write/submit an article about how I created the app with synth.

Answer 11 · 2014-08-12T05:38:27.000Z

That would be amazing!

On Mon, Aug 11, 2014 at 10:35 PM, Mikael Møller notifications@github.com
wrote:

My goal is to have an entire app done within the next two weeks. I should be able to open source it, I could write a "guest" post about how I created the app with synth.

Reply to this email directly or view it on GitHub:
#59 (comment)

Answer 12 · 2014-08-12T19:43:28.000Z

I have now added the params service to the default template. But I also introduced a second route that uses it. The getTweet/showing single tweets (as you did in the demo at the angular meetup)

mikaelhm@4e378ca

Do you think its too much? Should it be left as part of the tutorial?

Also I consider adding both the json and urlencode to the params module, so it would be:

var _ = require('lodash');
var Promise = require('bluebird');
var bodyParserJSON = Promise.promisify(require('body-parser').json());
var bodyParserURLencoded = Promise.promisify(require('body-parser').urlencoded({extended: true}));

exports.params = function (req, res) {
  // Combines the three sources of parameters into one, and return them in one object
  // Similar to how Rails and various other frameworks do it
  return bodyParserJSON(req, res)
    .then(function () {
        return bodyParserURLencoded(req, res);
    })
    .then(function () {
      return _.merge({}, req.query, req.params, req.body);
    });
};

Answer 13 · 2014-08-12T19:51:40.000Z

Also I modified the synth routes command to only print the header once:
mikaelhm@90ca40b

I guess that was the intended behaviour.

Answer 14 · 2014-08-12T20:51:34.000Z

Do you think its too much? Should it be left as part of the tutorial?

I do want to keep the template slim, since I want people to use it for their own projects, and don't want them to have to delete too much. But at the same time, it should demonstrate basic functionality, so it is a balance. I'd say leave it for the tutorial.

Also I modified the synth routes command to only print the header once

Huh, nice find :)

Answer 15 · 2014-08-12T20:56:07.000Z

I'd say leave it for the tutorial.
Ok, so we keep the params service, but don't use it. I'm ok with that.

I can fill in the blank part of the tutorial

Answer 16 · 2014-08-12T20:59:59.000Z

Sure, that's fine too.

On Tue, Aug 12, 2014 at 1:56 PM, Mikael Møller notifications@github.com
wrote:

I'd say leave it for the tutorial.
Ok, so we keep the params service, but don't use it. I'm ok with that.

I can fill in the blank part of the tutorial

—
Reply to this email directly or view it on GitHub
#59 (comment).

Answer 17 · 2014-08-12T21:04:19.000Z

I was also looking at adding a section about the whole DI in endpoints and services.

But first I realized that the back-app.js is a bit odd now, as we should be able to use services for the most of what we used to put in here.

I think we should keep the back-app.js file, as it is nice to have a place to do custom changes. But what about the docs. do we have another good example of what it could be used for.

Answer 18 · 2014-08-12T22:33:07.000Z

It could be used for setting up old-fashioned Connect middleware. Maybe a
cookie parser?

On Tue, Aug 12, 2014 at 2:04 PM, Mikael Møller notifications@github.com
wrote:

I was also looking at adding a section about the whole DI in endpoints and
services.

But first I realized that the back-app.js
http://www.synthjs.com/docs/#back-app-js is a bit odd now, as we should
be able to use services for the most of what we used to put in here.

I think we should keep the back-app.js file, as it is nice to have a
place to do custom changes. But what about the docs. do we have another
good example of what it could be used for.

—
Reply to this email directly or view it on GitHub
#59 (comment).

Answer 19 · 2014-08-12T23:02:46.000Z

back-app.js could be made optional too. If it's there, try to load it, if it gets an express app, run it, otherwise init and run one automatically.

Answer 20 · 2014-08-13T00:13:20.000Z

I like that, then it can be less important in the docs.
Den 12/08/2014 16.02 skrev "Jon Abrams" notifications@github.com:

back-app.js could be made optional too. If it's there, try to load it, if
it gets an express app, run it, otherwise init and run one automatically.

—
Reply to this email directly or view it on GitHub
#59 (comment).

Answer 21 · 2014-08-13T18:47:56.000Z

I updated the api-part of the existing example in the tutorial.

mikaelhm@d8cf2be

I will be busy the rest of the week, and probably not be able to do much on Synth until next week.
Would you like a PR of the current work or still want to wait a bit?

-m

Answer 22 · 2014-08-13T18:52:33.000Z

A PR would be great, thanks so much!

On Wed, Aug 13, 2014 at 11:47 AM, Mikael Møller notifications@github.com
wrote:

I updated the api-part of the existing example in the tutorial.

mikaelhm/synth@d8cf2be
mikaelhm@d8cf2be

I will be busy the rest of the week, and probably not be able to do much
on Synth until next week.
Would you like a PR of the current work or still want to wait a bit?

-m

—
Reply to this email directly or view it on GitHub
#59 (comment).

Answer 23 · 2014-09-21T00:19:39.000Z

0.6.0 is available now.

I just created an account on medium.com to check, you can create a collection called synth or synthjs and you will then be the owner, you are then in control of everything that goes in that collection(see more in this post)

My goal is to have an entire app done within the next two weeks. I should be able to open source it, I could write a "guest" post about how I created the app with synth.