atom / teletype-server

Server-side application that facilitates peer discovery for collaborative editing sessions in Teletype

Atom and all repositories under Atom will be archived on December 15, 2022. Learn more in our official announcement

teletype-server

The server-side application that facilitates peer discovery for collaborative editing sessions in Teletype.

Hacking

Dependencies

To run teletype-server locally, you'll first need to have:

• Node 7+
• PostgreSQL 9.x
• An app on pusher.com
• An OAuth app on github.com

Running locally

1. Clone and bootstrap

   git clone https://github.com/atom/teletype-server.git
   cd teletype-server
   cp .env.example .env
   createdb teletype-server-dev
   createdb teletype-server-test
   npm install
   npm run migrate up
   

2. Copy the app_id, key, and secret for your app on pusher.com, and set those values in your .env file

3. Copy the client ID and client secret for your OAuth app on github.com, and set those values in your .env file

4. Start the server

   ./script/server
   

5. Run the tests

   npm test
   

Deploying

Atom core team members can use this guide to test pull requests and deploy changes to production.

teletype-server's Issues

Add functionality to negotiate github oauth token generation

Would it make sense to include the github app oauth functionality to be served from / and not just the https://teletype.atom.io/auth/teletype/token site?

The atom package could link to the configured teletype-server and negotiate the necessary oauth token generation.

Add github enterprise support

It'd be cool to be able to configure and host your own server internally.

Teletype for on-prem?

Is it possible to start a fork of teletype-server without dependency on Pusher or is it tied to all communication?

Thanks,
Steve

error: password authentication failed for user

If you are running on your own server, you may also need the following environment variables for PostgreSQL:

PGDATABASE=dbname
PGPASSWORD=password
PGUSER=username

TextNow log

textnow (1).log

Summary

Motivation

Describe alternatives you've considered

Additional context

Cache Twilio ICE servers until TTL expires to avoid hammering Twilio API

Twilio issues ICE server credentials with a timeout, so we can't just fetch them at server startup. Because of this, I switched to fetching them prior to every peer connection by our clients in 0ac7432. The problem with this is it hammers the Twilio API and puts it on the critical path to our peer connections, which isn't ideal.

We should instead cache the ICE servers for a specific time period and fetch them once per TTL period.

/cc @jasonrudolph @as-cii

RFE: allow use of different authentications systems than github.com for corporative use

For corporative use, it would be nice to have a dedicated teletype server , that points to a different authentication system. For example, even github can be github.the.corporation.com , instead of github.com .

Improve handling of Twilio internal server errors

Around 23:01:07 UTC on Dec 2nd, we experienced a handful of timeouts when trying to contact the Twilio API [1]. Thanks to the health check, we were alerted to the issue. However, the issue also resulted in exceptions being reported to Bugsnag [2], probably due to the lack of error handling in the GET /ice-servers endpoint.

If Twilio responds with an internal server error, we shouldn't clutter Bugsnag with that info. Instead, we should detect that Twilio has experienced an internal server error and respond with an error code of our own. If the issue persists, we can rely on the health check to alert us to the problem.

---

[1] Request logs:

Dec 02 22:53:57 atom-teletype heroku/router:  at=info method=GET path="/_ping" host=api.teletype.atom.io request_id=595c1138-9d17-45d5-981e-fc60398fcd96 fwd="REDACTED" dyno=web.1 connect=1ms service=6051ms status=503 bytes=298 protocol=https
Dec 02 23:00:44 atom-teletype heroku/router:  at=info method=GET path="/_ping" host=api.teletype.atom.io request_id=b9aae493-942f-4ea7-a964-d573fcdef91a fwd="REDACTED" dyno=web.2 connect=0ms service=6071ms status=503 bytes=298 protocol=https
Dec 02 23:00:58 atom-teletype heroku/router:  at=info method=GET path="/_ping" host=api.teletype.atom.io request_id=b9747980-60bc-4046-acb9-5b05d55aa4d2 fwd="REDACTED" dyno=web.2 connect=0ms service=6067ms status=503 bytes=298 protocol=https
Dec 02 23:01:04 atom-teletype heroku/router:  at=error code=H12 desc="Request timeout" method=GET path="/ice-servers" host=api.teletype.atom.io request_id=2d948f90-8e86-4a74-9502-fb20fbfd129f fwd="REDACTED" dyno=web.1 connect=0ms service=30000ms status=503 bytes=0 protocol=https
Dec 02 23:01:10 atom-teletype heroku/router:  at=info method=GET path="/_ping" host=api.teletype.atom.io request_id=06e1ef51-c42f-4943-96a8-06375ad62972 fwd="REDACTED" dyno=web.2 connect=0ms service=6058ms status=503 bytes=298 protocol=https
Dec 02 23:01:23 atom-teletype heroku/router:  at=error code=H12 desc="Request timeout" method=GET path="/ice-servers" host=api.teletype.atom.io request_id=2b586b10-f872-40a7-9bda-30918072e9d2 fwd="REDACTED" dyno=web.2 connect=1ms service=30000ms status=503 bytes=0 protocol=https
Dec 02 23:01:23 atom-teletype heroku/router:  at=info method=GET path="/_ping" host=api.teletype.atom.io request_id=82c0da9a-5d0c-46de-87b2-e909fd99c1ba fwd="REDACTED" dyno=web.1 connect=1ms service=6042ms status=503 bytes=298 protocol=https
Dec 02 23:01:31 atom-teletype heroku/router:  at=error code=H12 desc="Request timeout" method=GET path="/ice-servers" host=api.teletype.atom.io request_id=c8e35e55-fbe3-4feb-8a2f-9a3ea3186a47 fwd="REDACTED" dyno=web.2 connect=1ms service=30002ms status=503 bytes=0 protocol=https

---

[2] Exception details in Bugsnag:

StatusCodeError 500 - "{\"code\": 20500, \"message\": \"An internal server error has occurred\", \"more_info\": \"https://www.twilio.com/docs/errors/20500\", \"status\": 500}"
    /app/node_modules/request-promise-core/lib/errors.js:32:15 new StatusCodeError
    /app/node_modules/request-promise-core/lib/plumbing.js:104:33 callback
    /app/node_modules/request-promise-core/lib/plumbing.js:46:31 RP$callback [as _callback]
    /app/node_modules/request/request.js:188:22 callback
    events.js:106:13 emitTwo
    events.js:194:7 emit
    /app/node_modules/request/request.js:1171:10 none
    events.js:96:13 emitOne
    events.js:191:7 emit
    /app/node_modules/request/request.js:1091:12 none
    events.js:293:19 onceWrapper
    events.js:91:20 emitNone
    events.js:188:7 emit
    /app/node_modules/newrelic/lib/transaction/tracer/index.js:183:28 wrapped
    /app/node_modules/newrelic/lib/transaction/tracer/instrumentation/outbound.js:97:26 wrappedResponseEmit [as emit]
    _stream_readable.js:975:12 endReadableNT
    /app/node_modules/newrelic/lib/transaction/tracer/index.js:183:28 wrapped
    internal/process/next_tick.js:80:11 _combinedTickCallback
    internal/process/next_tick.js:128:9 _tickDomainCallback
    /app/node_modules/newrelic/lib/transaction/tracer/index.js:284:51 wrappedFunction

Attempt to fetch portal with invalid UUID sends error to Bugsnag

Seen in bugsnag:

https://app.bugsnag.com/atom-tachyon/atom-tachyon/errors/5a0414e38d595a001a0599e8?&event_id=5a04a8a7c5f5710018ce111f

error /app/node_modules/pg/lib/connection.js:539

invalid input syntax for uuid: "b9106b2ecdcf336c5df16096890e29a4ef8f1bcc"

Linked event: 1 hour ago · Nov 9th, 19:12:39 UTC

error invalid input syntax for uuid: "acb1f8fe4a92e09869061fd5c633fcdce2b6019b" 
    /app/node_modules/pg/lib/connection.js:539:11 parseE
    /app/node_modules/pg/lib/connection.js:366:17 parseMessage
    /app/node_modules/pg/lib/connection.js:105:22 none
    events.js:96:13 emitOne
    events.js:191:7 emit
    _stream_readable.js:178:18 readableAddChunk
    _stream_readable.js:136:10 push
    net.js:561:20 onread

---

Expected behavior: The app should gracefully handle invalid portal ID values. If a user attempts to fetch the info for a portal using an invalid portal ID, the app should respond with a 404 and no error should get logged to Bugsnag.

RFE: remove pusher.com dependency

Similarly to #33: in order to deploy a full private solution, a private server could be easily deployed via docker, given an almost-standardish nodejs Dockerfile.

Nevertheless, pusher.com is an hosted solution, which could be not desirable for organizations with an high confidentiality policy. Their on-premise solution is presumed to be expensive, but this is not what I'm discussing.

Is there any chance of replacing pusher.com with an OSS equivalent solution?

Is using a UUID as a primary key in Postgres a performance hazard?

I recall using UUID as primary keys in MySQL as a younger engineer, only to learn that it was a disaster for write performance since tables are ordered by primary key by default on disk and using UUIDs created a random ordering among all records instead of an increasing one. Should we use an integer primary key on the portals table and add a secondary index for the id column instead? Maybe Postgres is smarter than MySQL was back in the day and this doesn't matter.

Enable auto-scaling on Heroku

I have enabled auto-scaling on atom-tachyon by:

• Switching to a Performance-M dyno (https://devcenter.heroku.com/articles/dyno-types#available-dyno-types).
• Setting a minimum of 1 dyno.
• Setting a maximum of 4 dynos.
• Setting the scaling strategy to achieve 500ms response time on 95th percentile.
• Enabling e-mail notifications when dynos can't be scaled up if they exceed the aforementioned maximum.

/cc: @jasonrudolph @nathansobo