Después de meses de trabajar en eso quiero compartir algunas cosas que aprendí.

Terminar de leer!

Originally published at sergiodxa.com.

And after months working on it I want to share some thinks I learned.

Read more!

Originally published at sergiodxa.com.

En este artículo vamos a ver como se puede crear un parser que transforme Markdown en componentes de React, pasando por HTML y JSON en el proceso

Terminar de leer

Originally published at sergiodxa.com.

Renderizando Markdown en React.js was originally published in React & Redux on Medium, where people are continuing the conversation by highlighting and responding to this story.

Being realistic tests are usually avoided and this happens even often in Frontend codebases because testing a UI is harder than just doing a unit test or a HTTP request to check the response of an API (I’m not saying testing backend is easy).

The problem here is that doing tests is important and avoiding them is just irresponsible, they allow the early detection of bugs before reaching the users.

Here I’m going to list and review some useful techniques when testing Frontend code that can be gradually implemented.

Read more!

That’s why I want to share how you can learn what to learn and where you can find information.

Find information

There’s a lot of places to find information. I found there are some places I always visit to get more info.

Mozilla Developer Network

Also known as MDN. This site is basically the documentation of web technologies. If you want to read about a HTML tag, a CSS attribute or a any JS related thing you must go there.

CanIUse

A really nice place to check the support of a feature in multiple browsers. It also gives you information about the usage of that browser (personal recommendation: if a browser doesn’t have more than 5% of usage don’t support it)

Specific documentations

Usually you use only a certain technologies, your personal stack. always check the documentation of that technologies to learn more, usually they have a blog, twitter accounts, a Github organization, etc. you can use to get more knowledge.

Awesome lists

Awesome is an idea started by sindresorhus. They are list of useful links about any technology. The main list (linked in the title) is a list of other awesome lists like awesome-javascript, awesome-react, awesome-redux, and more. This lists are really useful to find libraries, articles, talks, videos, etc. etc. about any specific technology.

Follow developers

Almost every developer have a Twitter account and they share a lot of interesting projects they’re working on or follow. And most important, they share ideas and have discussions you can read to learn a lot.

Because of that I created a Twitter List with many people, and of course follow them.

@sergiodxa/Developers/Designers on Twitter

☝️ That’s the list, I always have a column in Tweetdeck with that list open. Try following that list of some members. They’re really awesome.

Read a lot

I’m always reading about the technologies I’m interested.

Medium

Medium it’s a great place to read, personally I like to follow tags so I can get articles from many authors and publications. The tags I follow are

• API
• Apollo Client
• Apollostack
• Authentication
• AWS
• Babeljs
• Cloud Computing
• Components
• Css in Js
• Css Modules
• Desktop App
• DevOps
• Django
• Docker
• Electrode
• Electron
• Electronjs
• Elm
• Erlang
• ES6
• Flux
• Functional Programming
• GraphQL
• High Order Component
• Iaas
• Immutablejs
• Isomorphic Applications
• JavaScript
• Json Web Token
• Kubernetes
• Meteor
• Microservices
• Monads
• Nextjs
• Nodejs
• NPM
• Observables
• Orchestation
• Paas
• Progressive Web App
• React
• React Native
• React Router
• Reactjs
• Recompose
• Redux
• Redux Saga
• Relay
• Reselect
• Rest Api
• Rxjs
• SaaS
• Server Rendering
• Serverless
• Service Worker
• Single Page Applications
• Styled Components
• UI
• UX
• Web Apps
• Webpack
• Websocket

I also follow some folks and publications like:

• React Redux (spanish)
• Learning React.js
• Udacity Eng & Data
• Netflix TechBlog
• Reactive Conf
• Apollo GraphQL
• Zeplin Gazette
• Airbnb Engineering & Data Science
• Several People Are Coding
• GET PUT POST
• Making Meetup
• Code Cartoons
• WalmartLabs
• Serverless Zone
• Aerolab Stories
• Entendiendo JavaScript (spanish)
• webpack
• MeetupJS (spanish)
• JavaScript Scene
• A Cloud Guru
• Slack Platform Blog
• Scale API

Engineering blogs

Many startups have engineering related blogs. In this kind of blogs they tell why they choose their stack or introduce technologies they create. Some of the publications I listed above are engineering blogs like the Slack Platform Blog, WalmartLabs and one of my favorites Netflix TechBlog. Other blogs:

• GitHub Engineering
• Dev.Opera
• Facebook Code

Dev.to

Dev.to is a developer oriented community and blogging platform. It’s similar to Medium but only for development articles. Here you can follow tags or people and read a lot of articles and opinions about technology and development.

Personal blogs

I used to read a lot personal blogs, I still follow and read some blogs like PonyFoo or 2ality. Most of them migrated to Medium or dev.to so you can get more articles in that platforms.

Development blogs

Aside of Medium and Dev.to there are more blogs with many authors like CSSTricks, Codrops, Treehouse Blog, The npm Blog, The GitHub Blog, SurviveJS, Smashing Magazine, Scotch, React blog or Mozilla Hacks.

EchoJS

EchoJS is a website with the same idea of HackerNews, anyone can post interesting links, the only rules are they need to be JS related and in english. You can follow his Twitter account, access the website or follow the RSS feed to get all the links shared.

I found this site to be one of my biggest sources of links and articles about JS and related technologies. Instead of following a lot of blogs you can have a single curated list of articles.

Reddit

Particularly the JS subreddit, and other specific subreddit like React, Frontend, React Native, Redux, GraphQL, etc. It’s basically the same idea as EchoJS, a curated feed of links.

Watch talks

I mentioned talks many times above. Watch talks and conferences about JS, the community is huge and we have many conferences about JS. The JSConf, alongside the country specific JSConf always have amazing talks.

Not only watch the talks in Youtube assist to them! There’re JSConf in many countries like JSConf AR, JSConf UY, JSConf CO, JSConf US, JSConf EU and more! And not only JSConf, NodeConf, NodeSummit, ReactConf, ▲ZEIT Day, etc.

Assist to meetups

Usually conferences are yearly. And only in capital cities. But meetups about any technology can be monthly, assist to meetups. A lot of cities have meetups and if your city doesn’t have one you can start it! Bring other developers and start doing meetups in your city.

Participate in communities

There exists many communities, they usually have a free Slack team you can join. ▲ZEIT community, ElmLang community, Reactiflux (react, RN, redux, GraphQL, Jest, Relay, etc.) community and more. Many development communities have their own Slacks, Discord or Gitter chats you can join.

Start participating can help you talk to the people who created the libraries and frameworks you use and with others in your same position.

Found useful Youtube channels

In Youtube exists a lot of channels, and some of them are related to development. Some cool channels you can follow are FunFunFunction, Facebook Developers, Netflix UI Engineering, Google Developers and node.js.

Many of them upload conferences videos, but other like FunFunFunction or Netflix UI Engineering upload videos specific for Youtube that are useful to learn more or watch different opinions about development.

Follow (and participate) in Github repositories

There’re many Github repositories you can follow and participate, that will let you know about the future of technologies you use daily. You can even participate sending Pull Requests, report or find bugs (and hopefully solutions to bugs) in their issues so they are awesome places to get more insights about frameworks or libraries you use.

Conclusion

There’re many ways to keep updated with technologies. Remember, development (and specially JavaScript and Frontend) is an always learning path. You’ll always be learning more and more and this has no end. So embrace that and keep learning!

A Node.js framework for creating GraphQL API servers easily and without a lot of boilerplate.

The core server code of any GraphQL API it’s always basically the same, create the HTTP server, get your resolvers and schema, set the /graphql endpoint, in development set the endpoint for GraphiQL and if you are going to use subscriptions also create a subscription server and attach it to your HTTP server.

That’s a lot of boilerplate code! And Grial will handle all of that for you and let you only think about your application business logic and API layer. How? Grial it’s a serie of many little libraries, the core are @grial/cli and @grial/server which would create your API server and run it with a single command.

Grial also have many connectors little libraries that allow you to easily connect your API to different data sources and enable the creation of a big API that consumes data from Redis, MongoDB, Rest APIs, file disk, etc.

Let’s code an API!

Time to code, we’ll create a directory for the API and install this modules.

yarn add @grial/cli @grial/server @grial/connector-faker

The last one it’s a connector for the faker module and we are going to use it to fake our API data. Then we are going to add the following script to our package.json file.

{
  "scripts": {
    "start": "grial start"
  }
}

That script will use @grial/cli to run our @grial/server, it’ll also try to read our environment variables from a .env file, we can then create one with this basic variables.

PORT=8000

By default it will set PORT=3000, every Grial module have the required and possible environment variables in the readme.

Define the schema

After that we are ready to write our API code, let’s define our schema, Grial let us write it inside a schema.gql or a schema.graphql file, so we’re going to define something like this in one of them.

type User {
  id: Int!
  username: String!
  firstName: String!
  lastName: String!
  fullName: String!
  bio: String!
}

type Query {
  me: User!
}

schema {
  query: Query
}

Write the resolvers

Now we need to create a resolvers.js files. Along with the schema these are the only required files.

// main resolvers
exports.Query = {
  me(rootQuery, args, context) {
    return context.models.User.me();
  }
};

// type resolvers
exports.User = {
  fullName(user) {
    return `${user.firstName} ${user.lastName}`;
  }
};

We exported many keys but we could also use module.exports and just export a single object with the keys Query and User.

My own personal recommendation is to use many exports, also as your resolvers grow create a resolvers directory with a file Query.js, Mutation.js, Subscription.js and one file for each type we need a custom resolver.

Create the models

As we saw we received the model User from our context object, Grial automatically will read our models.js file and instantiate each one. We will create this file now.

exports.User = async function User({ faker }) {
  return {
    me() {
      return {
        id: faker.random.number(),
        username: faker.internet.userName(),
        firstName: faker.name.firstName(),
        lastName: faker.name.lastName(),
        bio: faker.name.title()
      };
    }
  };
};

That’s our User model, again we used a name export but we could have done a single export with an object. If you check we are creating an async function for our model, that’s because we could require to run asynchronous code before creating our resolvers (maybe to synchronize the model with a database).

Import the connectors

We also received faker in our model, that’s our connector, each model receive a single parameter with each environment variable and connector that of course allow a single model to get data using multiple connectors.

So, we receive the connector, but how Grial knows that? Simple, just create a connectors.js object and export each connector you want to use.

exports.faker = require('@grial/connector-faker');

Those are our API connectors, we can use this file to also define custom connectors, maybe using third-party APIs clients. Every connector will receive every environment variable and it’s going to use some of them, the Faker connector use FAKER_LOCALE and FAKER_SEED and have default values.

If you want to use the same connector multiple times you can wrap them with a high order function which receive the environment variables and pass new ones.

exports.faker = env => require('@grial/connector-faker')({
  FAKER_LOCALE: env.DATA_LOCALE,
  FAKER_SEED: env.DATA_SEED
})

Running the app

With that done we have our API code ready, just run yarn start or npm start and you will see something like this in your terminal.

$ grial start
Grial server running
> GraphiQL Endpoint      = http://localhost:3000/ide
> API Endpoint           = http://localhost:3000/graphql
> Subscriptions Endpoint = http://localhost:3000/subscriptions

We can then access to http://localhost:3000/ide and try the API. As you can see Grial also set you a subscriptions endpoint by default, if you create a PubSub instance and add subscriptions to your schema and resolvers you can start using them without worries.

You can also try this application running in production accessing to https://grial-example-basic.now.sh/ide and another API built with Grial fetching data from a Rest API https://grial-example-rest-wrapper.now.sh/ide

The second example wrap the JSONPlaceholder API into a GraphQL one and add tests for the models and resolvers.

Final word

Grial allow to customize its behavior using a grial.config.js file with the keys graphqlConfig, graphiqlConfig and subscriptionConfig, they let you customize GraphQL, GraphiQL and the subscription server configurations, useful to include some token based authentication and other features.

It’s also pluggable, you can use the programmatically API to integrate it inside any HTTP server or application, it can be Next.js, Express.js, etc.

You can contribute to Grial and help create an awesome GraphQL framework with more connectors, features, tools, examples and a completed docs.

Platzi

I worked at Platzi for almost 2 years, it was a really cool job, I knew some amazing people who worked with me or were teachers in our courses. Some of them I now consider them as good friends.

I also learned a lot about Frontend, Backend, video streaming, DevOps, etc. I worked in many awesome projects for the platform like our live system, the discussion system, the React-Django server render implementation, our video player, etc.

I had the opportunity to open source some JS libraries, one of the most important is the Platzi’s markdown text editor Pulse Editor and a desktop application, made with Electron.js, Pulse.

▲ZEIT

After knowing ▲ZEIT and using their products and services I’m in love with that company and it’s mission.

Make Cloud Computing as Easy and Accessible as Mobile computing.

Deploy an app to production it’s the last most important step in any software development, you can code the best app but it means nothing if it’s not online and available for your users.

The ▲ZEIT mission it’s to make easy that step that is sometimes too complicated, specially when working with a microservices architecture.

My new job

I’m going to be a Support Engineer, what does that means? My job is help you use ▲ZEIT products and services without problem and guide you in the process if necessary.

It’s a really big career shift, I’m going to keep developing but in a different way. I need to develop to understand our products and services.

I need to know how to use Next.js in many ways and integrate it with other tools. I must know how use Now to deploy your applications and setup a deployment pipeline using it for any kind of application.

That means I will learn a lot, I will teach a lot of people and I will develop many applications to test different possible use cases of our products and services.

I also need to document a lot, since my primary job is teach how to use Now I must document it completely, and create a really good documentation so anyone can easily learn how to use it.

Why English?

Until now, I had the rule of only writing in Spanish, that was because I wanted to give more knowledge to the Spanish development community. But starting today I need to teach Now to any people in the world.

That’s way I decided to start writing in English today. I’m going to keep learning a lot and writing as far as I can but I’ll do it exclusively in English.

Next.js nos permite crear aplicaciones de React fácilmente y socket.io nos permite crear aplicaciones en tiempo real fácilmente ¿Qué mejor que combinarlos para crear aplicaciones de React en tiempo real fácilmente?

En este artículo vamos a ver como combinarlos para crear una aplicación que use ambas tecnologías para crear una app de chat simple, que muestre los mensajes antiguos al entrar a la página y luego mediante socket.io nos permita enviar y recibir mensajes.

Terminar de leer

Next.js nos deja crear aplicaciones de React con server render y sin configurar nada (entre otras cosas). Pero hay ocasiones en las que es necesario configurar algunas cosas, por ejemplo Babel.js, capaz para cambiar algo o agregar algún plugin.

Por esa razón Next.js nos permite modificar su configuración de Babel interna. Es muy simple, vamos a suponer que queremos configurar un alias usando Babel para que en vez de importar componentes usando ../components/header.js podamos hacer components/header.js desde cualquier parte de nuestra aplicación.

Terminar de leer

Next.js nos permite crear aplicaciones de React fácilmente con server render y sin configuración. En su versión 3 (actualmente beta) incluyen una nueva característica y es poder crear sitios estáticos.

¿Qué es un sitio estático? Básicamente poder generar archivos .html en disco y que podamos luego llevar a producción fácilmente con Github Pages, Surge, Now, AWS S3, etc. Una ventaja de los sitios estáticos es que al ser un simple archivo en disco entrar a una página es super rápido, a comparación de un sitio dinámico que requiere hacer peticiones a un API o a una BD y luego generar el HTML dinámicamente con los datos obtenidos y a diferencia de una típica SPA no enviamos un HTML vacío, si no que el HTML que tenemos en disco ya tiene el contenido que necesitamos.

Terminar de leer